[BUG] UBIFS corruption on powerpc 32-bit targets

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

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

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.

Thanks for all your support!
Best regards,
Tomas