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

[Zhihao Cheng <chengzhihao1@huawei.com>]

在 2026/2/7 0:14, Tomas Alvarez Vanoli 写道:
>> Are there any error/warning messages(from ubi/ubifs/flash driver) during
>> scanning?
> 
> Now in the mounting logs we get some ECC errors, but I am sure this comes from
> the way the image was dumped and flashed again, because I did not see this
> before. No truncation appears for the affected inode.
> 
> I have another board where the corruption happened, so I can analyze that one
> with the patches suggested too.
> On this other board, the error is the same but with a different file:
> 
> UBIFS (ubi1:0): UBIFS: mounted UBI device 1, volume 0, name "cfg"
> UBIFS (ubi1:0): LEB size: 126976 bytes (124 KiB), min./max. I/O unit sizes: 2048
> bytes/2048 bytes
> UBIFS (ubi1:0): FS size: 132943872 bytes (126 MiB, 1047 LEBs), max 1058 LEBs,
> journal size 6602752 bytes (6 MiB, 52 LEBs)
> UBIFS (ubi1:0): reserved for root: 4952683 bytes (4836 KiB)
> UBIFS (ubi1:0): media format: w5/r0 (latest is w5/r0), UUID
> DC7EC969-1F4D-4669-9D31-16C57EAB96DA, small LPT model
> UBIFS error (ubi1:0 pid 134): ubifs_iget: failed to read inode 123367, error -2
> UBIFS error (ubi1:0 pid 134): ubifs_lookup: dead directory entry
> 'common_userdata_compat.xml.gz', error -2
> UBIFS warning (ubi1:0 pid 134): ubifs_ro_mode: switched to read-only mode, error
> -2
> 
> There are no error messages in the mount log for this board, the node situation
> is the same, and there are no truncation operations for this node.
> 
> [me@mypc debug]$ grep -B8 -A5 123367 logs_from_mounting_second_board
> data 123362 seq 1375451 found 1 2048-2520
> padding bytes 2520:4096
> data 123364 seq 1375458 found 1 4096-4576
> padding bytes 4576:6144
> data 123365 seq 1375459 found 1 6144-6624
> padding bytes 6624:8192
> data 123366 seq 1375489 found 1 8192-8680
> padding bytes 8680:10240
> data 123367 seq 1375493 found 0 10240-10728
> padding bytes 10728:12288
> data 123368 seq 1375507 found 1 12288-13592
> padding bytes 13592:14336
> data 123369 seq 1375508 found 1 14336-15384
> padding bytes 15384:16384
> --
> ino 123363 seq 1375463 nlink 2 found 0 125168-125328
> padding bytes 125328:126976
> ---------- Start scan LEB 182 (main_first 11) ----------
> ---------- Start scan LEB 183 (main_first 11) ----------
> ino 123365 seq 1375465 nlink 1 found 1 0-160
> padding bytes 160:2048
> ino 123366 seq 1375466 nlink 1 found 0 2048-2208
> padding bytes 2208:4096
> dent 123367(common_userdata_compat.xml.gz) seq 1375486 found 1 4096-4184
> ino 123367 seq 1375487 nlink 1 found 0 4184-4344
> ino 123361 seq 1375488 nlink 2 found 0 4344-4504
> padding bytes 4504:6144
> ino 123367 seq 1375490 nlink 1 found 0 6144-6304
> padding bytes 6304:8192
> ino 123366 seq 1375492 nlink 1 found 1 8192-8352
> padding bytes 8352:10240
> dent 123368(ne_config.xml.gz) seq 1375496 found 1 10240-10320
> ino 123368 seq 1375497 nlink 1 found 0 10320-10480
> ino 123363 seq 1375498 nlink 2 found 0 10480-10640
> padding bytes 10640:12288
> ino 123367 seq 1375500 nlink 1 found 0 12288-12448
> padding bytes 12448:14336
> dent 123369(unit-11_config.xml.gz) seq 1375502 found 1 14336-14416
> ino 123369 seq 1375503 nlink 1 found 0 14416-14576
> ino 123361 seq 1375504 nlink 2 found 0 14576-14736
> padding bytes 14736:16384
> 
Looks like that it is the same problem.
> 
> Just as a summary of the whole thing:
> 
> - Happens only when we introduce 6.12.57 kernel into our testing system.
> 
> - The boards go from running 6.12.57, to 4.14.20, to 6.1.75 for testing old
> release. When the 6.1.75 tries to access files in the cfg volume, there we see
> the error.
The same ubifs image is loaded by 6.12.57, 4.14.20 and 6.1.75? And the 
ubi volume won't be formatted after switching kernel?
If I understand right, do you backport ubifs bugfix patches to 4.14? 
Following commits could corrupt the ubifs image, which may lead to the 
problem:
1. ee1438ce5dc4d67dd8dd1ff51583122a61f5bd9e ubifs: Check link count of 
inodes when killing orphans.
2. 4ab25ac8b2b5514151d5f91cf9514df08dd26938 ubifs: Fix 
ubifs_tnc_lookup() usage in do_kill_orphans()

It would be better to apply fix patches through 4.14~HEAD. (git log 
v4.14..HEAD fs/ubifs/)
> 
> - We don't see any warning or error messages from the kernel.
> 
> - It only happens in the two different powerpc cpu boards we have, not in the
> armv8 one. All the boards use fsl,ifc-nand and the same nand chip.
> 
> - ubi tests from mtd-utils succeed for the older and the newer kernel too.
> 
> 
> Best Regards,
> Tomas.
> 


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