[BUG] UBIFS corruption on powerpc 32-bit targets

[Zhihao Cheng]

在 2026/2/9 23:45, Tomas Alvarez Vanoli 写道:
>>>
>>> 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?
> 
> Yes, the same ubifs image is shared by the kernels/applications.
> 
>> If I understand right, do you backport ubifs bugfix patches to 4.14?
> 
> No we don't. The application that uses 4.14.20 is the read-only factory image,
> which is not updated normally. It mounts the ubi volume but it only reads a file
> from it, won't do much to it. This one in particular was compiled in 2018 for
> example, so it does not include those commits.

Is the ubifs mounted in readonly mode in 4.14?
If not, the do_kill_orphan process will be committed on flash.
> 
>> 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/)
> 
> By this you mean that these patches can lead to corruption when switching to a
> version of the kernel that does not have them? If that is what you mean, I don't
> think it is the case because we have been running 6.1 with these patches for
> more than a year and never seen the issue, however it appears within hours of
> introducing 6.12 into the mix.
> 
> Somehow there is some difference in between 6.12 and 6.1 that makes this error
> happen, but it could potentially have to do also with jumping from 6.12 to 4.14,
> even though jumping from 6.1 to 4.14 has not caused the problem for the past 1+
> year.
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.

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
> 
> Best regards,
> Tomas
> 
> 
> .
>