[BUG] UBIFS corruption on powerpc 32-bit targets

[Zhihao Cheng]

在 2026/2/11 0:40, Tomas Alvarez Vanoli 写道:
>> Is the ubifs mounted in readonly mode in 4.14?
>> If not, the do_kill_orphan process will be committed on flash.
> 
> No, it is not read only.
> 
>> The commit 3af2d3a8c56fe7dc24f60c4df0ab85b7ac941902("ubifs: Fix
>> unattached inode when powercut happens in creating") [v6.11] is
>> introduced between 6.1 and 6.12, which will add every inode into orphan
>> area at the begining of creation.
> 
> By creation you mean the first occurence of it or whenever there's an update?
> 
> If I understand correctly, what you suggest is that it's possible that as
> the new inode is added to orphan area and the board is reset and booted into the
> older kernel, which then cleans all the orphans even if they have link count,
> leaving the fs broken?
> 
> So, in other words, my understanding of what you say is that for
> 3af2d3a8c56fe7dc24f60c4df0ab85b7ac941902 to not break anything, any kernel that
> mounts the same partition needs ee1438ce5dc4d67dd8dd1ff51583122a61f5bd9e and
> 4ab25ac8b2b5514151d5f91cf9514df08dd26938 .

Correct.
> 
>> So, you may try option  1 or 2 and check whether the problem could happen:
>> 1. mount 4.14 readonly
>> 2. backport fix patches on 4.14
> 
> Potentially also replacing the 4.14 application with an application based on
> 6.1?

What does 'application' mean?
> 
> I am also interested in consistently reproducing this at my desk. I have been
> tinkering with adding a message + a 10 second delay at points in the ubifs code
> so that I can reset the board and boot the old kernel to trigger this behaviour.
> Would you know at which exact point/conditions it would make sense to add this?
> Or is it not possible?
> I do not fully understand your theory, I have read the docs for the fs but I
> have little experience with filesystem implementation in general, so I am not
> sure how feasible this "hack" is.

Apply following patch in 6.12:


Apply following patch in 4.14:


Run:
start kernel 6.12
$ touch $MNT/file # cmd will stuck, $MNT is the ubifs mntpoint
$ dmesg # you will see kernel message 'wait sync and write orphans', 
open another terminal
$ sync # open another terminal, you will see kernel message 'write 
orphan XX', and the 'touch' cmd goes on
$ dd if=/dev/mtd0 of=flash bs=1M
$ sync and poweroff

start kernel 4.14
$ flash_eraseall /dev/mtd0
$ dd if=flash of=/dev/mtd0 bs=1M # make sure mtd0 is not attached by ubi
$ ubiattach -m0
$ mount /dev/ubi0_0 temp # dmesg will show 'remove ino XX'
$ ls temp
ls: cannot access 'temp/file': No such file or directory
file
$ dmesg
[   69.200639] UBIFS error (ubi0:0 pid 1587): ubifs_iget [ubifs]: failed 
to read inode 65, error -2
[   69.206214] UBIFS error (ubi0:0 pid 1587): ubifs_lookup [ubifs]: dead 
directory entry 'file', error -2
[   69.207482] UBIFS warning (ubi0:0 pid 1587): ubifs_ro_mode [ubifs]: 
switched to read-only mode, error -2
[   69.208783] CPU: 2 PID: 1587 Comm: ls Not tainted 
4.19.90-00006-g332043630ae1-dirty #50
[   69.209837] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), 
BIOS ?-20190727_073836-buildvm-ppc64le-16.ppc.fedoraproject.org-3.fc31 
04/01/2014
[   69.211545] Call Trace:
[   69.211921]  dump_stack+0xb8/0xef
[   69.212370]  ubifs_ro_mode+0x54/0x60 [ubifs]
[   69.212950]  ubifs_lookup+0x3b6/0x550 [ubifs]
[   69.213535]  __lookup_slow+0x9e/0x210
[   69.214045]  lookup_slow+0x46/0x70
[   69.214491]  walk_component+0x265/0x4c0
[   69.215013]  path_lookupat.isra.0+0x9e/0x360
[   69.215588]  filename_lookup+0xb5/0x230
[   69.216107]  ? _raw_spin_unlock_irqrestore+0x3f/0x80
[   69.216769]  ? __this_cpu_preempt_check+0x17/0x20
[   69.217386]  ? __local_bh_enable_ip+0x62/0x110
[   69.218038]  ? _raw_spin_unlock_bh+0x2e/0x40
[   69.218761]  ? wb_wakeup_delayed+0x56/0x90
[   69.219301]  ? kmem_cache_alloc+0x110/0x3d0
[   69.219852]  user_path_at_empty+0x43/0x60
[   69.220391]  vfs_statx+0x90/0x150
[   69.220847]  ? __sb_end_write+0x5f/0xb0
[   69.221354]  __se_sys_newlstat+0x46/0xa0
[   69.221892]  ? __se_sys_getdents+0xe0/0x1c0
[   69.222465]  ? filldir64+0x340/0x340
[   69.222958]  __x64_sys_newlstat+0x1a/0x30
[   69.223499]  do_syscall_64+0x95/0x460
[   69.224004]  ? prepare_exit_to_usermode+0xaa/0x180
[   69.224652]  entry_SYSCALL_64_after_hwframe+0x5c/0xc1

> 
> Thanks for all your support!
> Best regards,
> Tomas
> .
>