Re: [BUG] UBIFS corruption on powerpc 32-bit targets

[Zhihao Cheng <chengzhihao1@huawei.com>]

在 2026/2/5 23:47, Tomas Alvarez Vanoli 写道:
> Hi,
> 
>> It would be appreciate that if you could modify according to the
>> suggestions and resend them.
> 
> I'll take look at the patch and submit the changes soon.
> 
>> Looks like that there is only one problem, the inode cannot be found but
>> the dentry(ne_config.xml.gz) still exists on flash. I guess the lost
>> inode is 3917759 in previous log.
>> Maybe the inode is
>>
>> UBIFS error (ubi1:0 pid 134): ubifs_iget: failed to read inode 3917759,
>> error -2
>> UBIFS error (ubi1:0 pid 134): ubifs_lookup: dead directory entry
>> 'ne_config.xml.gz', error -2
>> UBIFS warning (ubi1:0 pid 134): ubifs_ro_mode: switched to read-only
>> mode, error -2
>> find: /cfg/board/cfg/mob/backup/ne/ne_config.xml.gz: No such fiCPU: 1
>> UID: 0 PID: 134 Comm: find Not tainted 6.12.57-00435-gf9e139970f1f #0
>>
>> Apply following patch to kernel and mount bad ubifs image, let's try to
>> find more information after a full volume scanning:
> 
> I flashed again the corrupted image, the same error happens with "find /cfg",
> but also I get a couple ecc errors afterwards for some reason.
> 
> Here's some excerpts related to ino 3917759 from the full volume scan
> 
> ```
> ---------- Start scan LEB 911 (main_first 11) ----------
> data 3917758 found 1 98304-98792
> padding bytes 98792:100352
> data 3917759 found 0 100352-101792
> padding bytes 101792:102400

The 'data 3917759' means that ne_config.xml.gz has ever been written, 
the message 'found 0' means that ne_config.xml.gz was truncated or 
deleted later.

> data 3917760 found 1 102400-103464
> padding bytes 103464:104448
...
> ---------- Start scan LEB 912 (main_first 11) ----------
> ```
> 
> [...]
> 
> ```
> ---------- Start scan LEB 914 (main_first 11) ----------
> ino 3917758 found 0 0-160
> padding bytes 160:2048
> dent 13819078852795695104(ne_config.xml.gz) found 1 2048-2128

The dentry should be this one. 13819078852795695104 (0xbfc73b0000000000 
is the little endian in u64 format for 0x3bc7bf[3917759]).

> ino 3917759 found 0 2128-2288
> ino 3917754 found 0 2288-2448
> padding bytes 2448:4096

Above three items 'dent+ino[3917759]+dir ino[3917754]' should be a 
creation op,

> ino 3917758 found 1 4096-4256
> padding bytes 4256:6144
> ino 3917759 found 0 6144-6304
> padding bytes 6304:8192

Then, inode 3917759 is changed by some op(eg. write/delete).

So, file 'ne_config.xml.gz' was created and written, then following two 
ops may be executed:
1. truncate. No truncation nodes are found, maybe there are not printed, 
or they were gced later.
Apply following patch to verify it. Even so, ubifs makes sure that 
truncation is an atomic modification op on flash, the inode(found=1) is 
finally be scanned from the flash, it cannot be happened that inode is 
not found.

diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c
index 35d54e1a7ecd..274bdab606b3 100644
--- a/fs/ubifs/super.c
+++ b/fs/ubifs/super.c
@@ -1509,10 +1509,12 @@ static int mount_ubifs(struct ubifs_info *c)
  	while (len >= 8) {
  		int found;
  		int node_len;
+		unsigned long long seq;
  		struct ubifs_ch *ch = (struct ubifs_ch *)buf;
  		struct ubifs_ino_node *ino;
  		struct ubifs_dent_node *dent;
  		struct ubifs_data_node *dn;
+		struct ubifs_trun_node *trun;
  		union ubifs_key key;

  		ret = ubifs_scan_a_node(c, buf, len, lnum, offs, 0);
@@ -1531,6 +1533,7 @@ static int mount_ubifs(struct ubifs_info *c)
  		}

  		node_len = ALIGN(le32_to_cpu(ch->len), 8);
+		seq = le64_to_cpu(ch->sqnum);

  		switch (ch->node_type) {
  			case UBIFS_INO_NODE:
@@ -1538,21 +1541,25 @@ static int mount_ubifs(struct ubifs_info *c)
  				key_read(c, &ino->key, &key);

  				found = ubifs_tnc_has_node(c, &key, 0, lnum, offs, 0);
-				pr_info("ino %u found %d %d-%d\n", key.u32[0], found, offs, offs + 
node_len);
+				pr_info("ino %u seq %llu nlink %u found %d %d-%d\n", key.u32[0], 
seq, le32_to_cpu(ino->nlink), found, offs, offs + node_len);
  				break;
  			case UBIFS_DENT_NODE:
  				dent = (struct ubifs_dent_node *)buf;
  				key_read(c, &dent->key, &key);

  				found = ubifs_tnc_has_node(c, &key, 0, lnum, offs, 0);
-				pr_info("dent %llu(%s) found %d %d-%d\n", dent->inum, dent->name, 
found, offs, offs + node_len);
+				pr_info("dent %llu(%s) seq %llu found %d %d-%d\n", 
le64_to_cpu(dent->inum), dent->name, seq, found, offs, offs + node_len);
  				break;
  			case UBIFS_DATA_NODE:
  				dn = (struct ubifs_data_node *)buf;
  				key_read(c, &dn->key, &key);

  				found = ubifs_tnc_has_node(c, &key, 0, lnum, offs, 0);
-				pr_info("data %u found %d %d-%d\n", key.u32[0], found, offs, offs + 
node_len);
+				pr_info("data %u seq %llu found %d %d-%d\n", key.u32[0], seq, 
found, offs, offs + node_len);
+				break;
+			case UBIFS_TRUN_NODE:
+				trun = (struct ubifs_trun_node *)buf;
+				pr_info("trun %u seq %llu %d-%d\n", le32_to_cpu(trun->inum), seq, 
offs, offs + node_len);
  				break;
  			default:
  				pr_info("unknown type %d\n", ch->node_type);

2. delete. The ubifs will pack dentry/inode/dir_inode into an atomic 
modification op on flash, it cannot be happened that dentry exists but 
inode is deleted.

Are there any error/warning messages(from ubi/ubifs/flash driver) during 
scanning?

> ```
> 
> There's also a second dent found in the tree for ne_config.xml.gz (there's
> another file named the same elsewhere), probably irrelevant:
> 
> ```
> padding bytes 29056:30720
> dent 14323482011061190656(ne) found 1 30720-30784
> ino 3917766 found 0 30784-30944
> ino 3917765 found 0 30944-31104
> padding bytes 31104:32768
> dent 14395539605099118592(ne_config.xml.gz) found 1 32768-32848
> ino 3917767 found 0 32848-33008
> ino 3917766 found 0 33008-33168
> padding bytes 33168:34816
> ino 3917767 found 0 34816-34976
> padding bytes 34976:36864
> ```
> 
> The full logs are roughly 120 thousand lines, let me know if you need me to
> search for something or would like them filtered differently.
> 
> Best Regards,
> Tomas
> 
> 
> .
> 


______________________________________________________
Linux MTD discussion mailing list
http://lists.infradead.org/mailman/listinfo/linux-mtd/