[BUG] UBIFS corruption on powerpc 32-bit targets

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

> 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.

Best regards,
Tomas