[LEDE-DEV] Kernel 4.9 rename/mv problem at least with ubifs+overlayfs, possibly with other filesystems

[Hannu Nyman]

I noticed this with a mvebu device but the bug may concern all kernel 4.9 
users with ubifs, and possibly also jffs2 users, meaning practically all 
targets...

Router fails to rename files that are both in /rom and in /overlay, i.e. they 
were part of the original flash and have been modified later or were included 
in sysupgraded config files.    ( I use /etc/dropbear/dropbear_rsa_host_key 
as an example testcase as that file is found in practically all builds.)

* Rename/mv fails.
* Deleting the same file succeeds.
* Copying is also ok.
(Deleting the file and copying a new one into its place does not enable 
rename, which still fails.)

As the problem is in the core filesystem level, the rename failure happens in 
all places: console, scripts and function calls from C programs.

Longer debug story and fix proposal for ubifs:
https://bugs.lede-project.org/index.php?do=details&task_id=579

The reason I am highlighting this at the mailing list is that after looking 
again at the original Linux upstream commit, I noticed that also jffs2 is 
among the filesystems that got the same new clause returning EINVAL error for 
certain rename action types. That may mean that also non-ubi targets are 
impacted with this. But I have no way of testing that.

The offending two new lines in kernel 4.9 fs/ubifs/dir.c :
     if (flags & ~RENAME_NOREPLACE)
         return -EINVAL;

Linux upstream commit that apparently restricts allowed rename action types, 
possibly breaking overlayfs actions:
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?h=linux-4.9.y&id=f03b8ad8d38634d13e802165cc15917481b47835

I drafted a fix for ubifs (in FS#579) that seems to work by removing the two 
new lines from fs/ubifs/dir.c that were not in our kernel 4.4 ubifs patches. 
Otherwise the kernel 4.4 ubifs LEDE patches are pretty identical to the 
upstream ubifs files in 4.9.

But I wonder if a better solution would be to change the RENAME flags in the 
call from overlayfs instead, or something like that. My fs skills are not 
good enough to determine the best solution.

I find this bug rather nasty as it makes a basic filesystem operation fail 
rather mysteriously. I originally spotted this when I was debugging opkg for 
Jow and first thought it to be a bug inside opkg, but after some debugging 
with strace it turned out to be a failing rename operation at the filesystem 
level.

Hopefully some filesystem gurus can look into this.