<feed xmlns='http://www.w3.org/2005/Atom'>
<title>mtd-utils.git/ubifs-utils/fsck.ubifs/problem.c, branch v2.3.1</title>
<subtitle>A mirror of http://git.infradead.org/mtd-utils.git</subtitle>
<id>https://git.infraroot.at/mtd-utils.git/atom?h=v2.3.1</id>
<link rel='self' href='https://git.infraroot.at/mtd-utils.git/atom?h=v2.3.1'/>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/'/>
<updated>2026-04-13T05:32:41+00:00</updated>
<entry>
<title>fsck.ubifs: fix platform dependant ino_t and loff_t formatting</title>
<updated>2026-04-13T05:32:41+00:00</updated>
<author>
<name>Yuta Hayama</name>
<email>hayama@lineo.co.jp</email>
</author>
<published>2026-02-13T13:55:22+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=a505a2cc56acf493607fdf24cbf129393a0873fa'/>
<id>urn:sha1:a505a2cc56acf493607fdf24cbf129393a0873fa</id>
<content type='text'>
On architectures such as armv7-a, ino_t and loff_t are unsigned long long rather than
unsigned long. In such cases, the printf format specifier "%lu" is not
appropriate and causes an incorrect address offset.

  mtd-utils/ubifs-utils/fsck.ubifs/problem.c:224
  		log_out(c, "problem: %s, ino %lu, unreachable dentry %s, type %s%s",
  			problem-&gt;desc, ifp-&gt;file-&gt;inum,
  			c-&gt;encrypted &amp;&amp; !ifp-&gt;file-&gt;ino.is_xattr ? "&lt;encrypted&gt;" : dent_node-&gt;name,
  			ubifs_get_type_name(dent_node-&gt;type),
  			key_type(c, &amp;dent_node-&gt;key) == UBIFS_XENT_KEY ? "(xattr)" : "");

  fsck.ubifs[484] (/dev/ubi0_0,danger mode): problem: Dentry is unreachable, ino 917, unreachable dentry (null), type checksum_typefile

Furthermore, running fsck.ubifs with the --debug=4 option will almost
certainly cause a SEGV at the following point.

  mtd-utils/ubifs-utils/fsck.ubifs/check_files.c:103
  	dbg_fsck("construct file(%lu) for %s node, TNC location %d:%d, in %s",
  		 inum, ubifs_get_key_name(key_type(c, key)), sn-&gt;lnum, sn-&gt;offs,
  		 c-&gt;dev_name);

To ensure functionality regardless of environment, cast ino_t to unsigned
long, since it will never be more than 4 bytes.

For loff_t, use %lld and cast accordingly.

Signed-off-by: Yuta Hayama &lt;hayama@lineo.co.jp&gt;
Signed-off-by: Tomas Alvarez Vanoli &lt;tomas.alvarez-vanoli@hitachienergy.com&gt;
Reviewed-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>fsck.ubifs: Handle disconnected files</title>
<updated>2024-11-11T09:32:46+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T09:08:15+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=2400ee616991542f39a154fe8c3cafe8ef940003'/>
<id>urn:sha1:2400ee616991542f39a154fe8c3cafe8ef940003</id>
<content type='text'>
This is the 17/18 step of fsck. Recover disconnected files into
lost+found. If there is no free space left to recover the disconnected
files, fsck may delete the files to make filesystem be consistent.

Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>fsck.ubifs: Check and create the root dir</title>
<updated>2024-11-11T09:32:46+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T09:08:13+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=b064a78fb9a9503a4bf87a5149ca8fe5711b2cff'/>
<id>urn:sha1:b064a78fb9a9503a4bf87a5149ca8fe5711b2cff</id>
<content type='text'>
This is the 15/18 step of fsck. Check whether the root dir is existed,
create a new one if it is not found. This step makes sure that filesystem
can be mounted successful.

Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>fsck.ubifs: Check and correct the index size</title>
<updated>2024-11-11T09:32:46+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T09:08:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=7e6ae3a8dcbedf0e65c091e985aff56f293cf8ec'/>
<id>urn:sha1:7e6ae3a8dcbedf0e65c091e985aff56f293cf8ec</id>
<content type='text'>
This is the 14/18 step of fsck. Check and correct the index size by
traversing TNC just like dbg_check_idx_size does. This step should
be executed after first committing, because 'c-&gt;calc_idx_sz' can be
changed in 'ubifs_tnc_start_commit' and the initial value of
'c-&gt;calc_idx_sz' read from disk is untrusted.

Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>fsck.ubifs: check and correct the space statistics</title>
<updated>2024-11-11T09:32:46+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T09:08:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=83b7477eae174e974237685f83f0fec4fb794892'/>
<id>urn:sha1:83b7477eae174e974237685f83f0fec4fb794892</id>
<content type='text'>
This is the 12/18 step of fsck. Check and correct the space statistics.
There could be following steps and possible errors:
 Step 1. Exit for check mode, if %FR_LPT_CORRUPTED or %FR_LPT_INCORRECT
 is set in lpt status, the exit code should have %FSCK_UNCORRECTED.
 Step 2. Check lpt status, if %FR_LPT_CORRUPTED is set in lpt status,
 normal mode with 'no' answer will exit, other modes will rebuild lpt.
 Step 3. Traverse LPT nodes, check the correctness of nnode and pnode,
 compare LEB scanning result with LEB properties.
  a. LPT node is corrupted, normal mode with 'no' answer will exit,
     rebuild lpt for other modes.
  b. Incorrect nnode/pnode, normal mode with 'no' answer will exit,
     other other modes will correct the nnode/pnode.
  c. Inconsistent comparing result, normal mode with 'no' answer
     will exit, other modes will correct the space statistics.
 Step 4. Check and correct the lprops table information.
 Step 5. Set gc lnum(ubifs_rcvry_gc_commit / take_gc_lnum).

Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>fsck.ubifs: Check whether the TNC is empty</title>
<updated>2024-11-11T09:32:46+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T09:08:07+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=59dd2cf5ad8e32c7b38b3287b9d05a2d809e93e4'/>
<id>urn:sha1:59dd2cf5ad8e32c7b38b3287b9d05a2d809e93e4</id>
<content type='text'>
This is the 11/18 step of fsck. Check whether the TNC is empty, turn to
rebuild_fs if it is not found. Can we recreate a new root dir to avoid
empty TNC? The answer is no, lpt fixing should be done before creating
new entry, but lpt fixing needs a committing before new dirty data
generated to ensure that bud data won't be overwritten(bud LEB could
become freeable after replaying journal, corrected lpt may treat it as
a free one to hold new data, see details in space checking &amp; correcting
step). Then we have to create the new root dir after fixing lpt and a
committing, znode without children(empty TNC) maybe written on disk at
the moment of committing, which corrupts the UBIFS image. So we choose
to rebuild the filesystem if the TNC is empty, this case is equivalent
to corrupted TNC.

Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>fsck.ubifs: Check and correct files' information</title>
<updated>2024-11-11T09:32:46+00:00</updated>
<author>
<name>Xiang Yang</name>
<email>xiangyang3@huawei.com</email>
</author>
<published>2024-11-11T09:08:06+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=d0b66b0e5bb346e795a4c0ac3cafd287a6e4db9d'/>
<id>urn:sha1:d0b66b0e5bb346e795a4c0ac3cafd287a6e4db9d</id>
<content type='text'>
This is the 10/18 step of fsck. Check and handle inconsistent files, the
checking rule is same as rebuild mode which has been implemented in
check_and_correct_files, but the methods of handling are different:
 1. Correct the file information for safe mode, danger mode and normal
    mode with 'yes' answer, other modes will exit.

Signed-off-by: Xiang Yang &lt;xiangyang3@huawei.com&gt;
Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>fsck.ubifs: Check and handle unreachable files</title>
<updated>2024-11-11T09:32:46+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T09:08:05+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=a251dd9c71006c66a02064210ae103ed7ac59444'/>
<id>urn:sha1:a251dd9c71006c66a02064210ae103ed7ac59444</id>
<content type='text'>
This is the 9/18 step of fsck. Check and handle unreachable files, the
checking rule is same as rebuild mode which has been implemented in
file_is_reachable, but the methods of handling are different:
1. Move unreachable regular file into disconnected list, let subsequent
   steps to handle them with lost+found.
2. Delete unreachable non-regular file.
3. Delete unreachable directory entries.

Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>fsck.ubifs: Check and handle invalid files</title>
<updated>2024-11-11T09:32:46+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T09:08:04+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=c5ca3893ea854e8d8b5916bc492db8523db70122'/>
<id>urn:sha1:c5ca3893ea854e8d8b5916bc492db8523db70122</id>
<content type='text'>
This is the 8/18 step of fsck. Check and handle invalid files, the
checking rule is same as rebuild mode which has been implemented in
file_is_valid, but the methods of handling are different:
 1. Move unattached(file has no dentries) regular file into disconnected
    list, let subsequent steps to handle them with lost+found.
 2. Make file type be consistent between inode, detries and data nodes by
    deleting dentries or data blocks.
 3. Delete file for other invalid cases(eg. file has no inode).

Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
<entry>
<title>fsck.ubifs: Ensure that TNC LEB can be scanned successful</title>
<updated>2024-11-11T09:32:46+00:00</updated>
<author>
<name>Zhihao Cheng</name>
<email>chengzhihao1@huawei.com</email>
</author>
<published>2024-11-11T09:08:02+00:00</published>
<link rel='alternate' type='text/html' href='https://git.infraroot.at/mtd-utils.git/commit/?id=e8ca613778e7e5449a038c5ea04b17977de97d74'/>
<id>urn:sha1:e8ca613778e7e5449a038c5ea04b17977de97d74</id>
<content type='text'>
This is the second part of 6/18 step in fsck. Add an extra checking for
non-check mode while traversing TNC, make sure that all LEBs(contains TNC)
can be scanned successful. There could be following steps and possible
errors:
 Step 2. Scan all LEBs(contain TNC), remove TNC branch which points to
 corrupted LEB.
  a. corrupted node is found by scanning: If current node is index node,
     danger mode with rebuild_fs and normal mode with 'yes' answer will
     turn to rebuild filesystem, other modes will exit; If current node
     is non-index node, danger mode and normal mode with 'yes' answer
     will remove all TNC branches which point to the corrupted LEB,
     other modes will exit.
  b. LEB contains both index and non-index nodes: danger mode with
     rebuild_fs and normal mode with 'yes' answer will turn to rebuild
     filesystem, other modes will exit.
This is a preparation for space checking, which means that ubifs_scan
will always succeed when check properties for any TNC LEBs. We do this
before checking files(step 7) &amp; extracting dentry tree(step 8), nodes
cannot be dropped(which may corrupted file and make file inconsistent
again) when scanning corrupted as long as the dentry tree is extracted.

Signed-off-by: Zhihao Cheng &lt;chengzhihao1@huawei.com&gt;
Signed-off-by: David Oberhollenzer &lt;david.oberhollenzer@sigma-star.at&gt;
</content>
</entry>
</feed>
