[BUG] UBIFS corruption on powerpc 32-bit targets

[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 at 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


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.

- 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