On Thu, Jul 5, 2018 at 7:32 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > On Thu, Jul 05, 2018 at 01:15:43PM -0300, Rafael David Tinoco wrote: >> > > commit 764baba80168ad3adafb521d2ab483ccbc49e344 >> > > Author: Amir Goldstein <amir73il@xxxxxxxxx> >> > > Date: Sun Feb 4 15:35:09 2018 +0200 >> > > >> > > ovl: hash non-dir by lower inode for fsnotify >> > > >> > > INFO: inotify issue with non-dir non-upper files in overlayfs exists >> > > in LTS <= v4.14. >> > > INFO: LTP inotify08 test fails on * v4.14 and bellow * and should be skipped. >> > > >> > > And message was informative only (clearly didn't work). Either way, do >> > > you think it's worth informing existing LTS bugs, found by test >> > > tooling, here ? >> > >> > Why can't we fix those bugs in the stable kernel releases? Is it too >> > difficult to do so? >> >> For this inotify bug: >> >> Commits >> >> ovl: hash non-dir by lower inode for fsnotify >> ovl: hash non-indexed dir by upper inode for NFS export >> ovl: do not pass overlay dentry to ovl_get_inode() >> ovl: hash directory inodes for fsnotify >> ovl: no direct iteration for dir with origin xattr >> Revert "ovl: hash directory inodes for fsnotify" >> >> are needed AND all the logic for setting up "origin" variable in >> ovl_lookup, passed to ovl_lookup_index() after it got its prototype >> changed, would still be missing (and other refactoring changes, >> commits splitting functions and so on). >> >> So I assumed it was a no-go. > > It all depends, let's get the git commit ids for these please. And have > you successfully applied and tested that those patches fix the issue? > If so, great, let's apply them! > >> There is also another bug: >> >> https://bugs.linaro.org/show_bug.cgi?id=3303. >> >> Fanotify faces a srcu dead-lock when userland stops responding to >> events for this other case. Fix for that bug is a 35 patches patchset >> (including the fix, commit 9dd813c15b2c101, for the particular >> issue). >> >> Question is, should I document things of this nature on this list also >> ? Even if it is likely a no-go for the backports ? Just as information >> ? Should I just bring the attention to the backport need (all patches) >> and you decide ? > > Same as above, if you test them and they work, and they resolve a > reported and testable bug, why wouldn't we apply them? > So this is the story with overlayfs - besides NFS export in v4.16, I don't think overlayfs got any new "features". Since the day it was merged upstream (v3.18) it was all about fixing bugs and "non-standard-behaviors": https://github.com/amir73il/overlayfs/wiki/Overlayfs-non-standard-behavior Are those non-standard behaviors reported and testable bugs? yes but they have been around for so long that applications may have become dependent on the non-standard-behavior, so the "bug fixes" are often introduced as "features" that are off by default and need to be explicitly enabled by config/module/mount option (e.g. redirect_dir added in v4.10). Now if you want to apply all the fixes to non-standard-behavior, I am maintaining a 4.9.y backport branch with *everything*: https://github.com/amir73il/linux/commits/overlayfs-4.9.y So this branch also includes the NFS export feature, but I suspect it going to be hairy to apply $SUBJECT fix in question without applying the NFS export patches. What does the new benevolent Greg have to say about this? Would you consider taking all non-standard-behavior fixes to stable? If you do, I can help with maintaining the stable overlayfs branches. Thanks, Amir.
