On Thu, Jul 05, 2018 at 09:28:56PM +0300, Amir Goldstein wrote: > 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. I'd prefer to stick with as close-to-possible as what Linus's tree has. But for stuff like this, maybe it just makes sense to leave it all alone and if people want the newer "features" they need to move to a newer kernel, like they should be doing anyway. So for now, let's just leave it as-is, if anyone complains we can revisit and look at the patches that are needed for backporting. sound reasonable? thanks, greg k-h
