[LTP] FAILED: patch "[PATCH] ovl: hash non-dir by lower inode for fsnotify" failed to apply to 4.14-stable tree
Greg KH
gregkh@linuxfoundation.org
Thu Jul 5 18:32:12 CEST 2018
On Thu, Jul 05, 2018 at 01:15:43PM -0300, Rafael David Tinoco wrote:
> > > commit 764baba80168ad3adafb521d2ab483ccbc49e344
> > > Author: Amir Goldstein <amir73il@gmail.com>
> > > 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?
thanks,
greg k-h
More information about the ltp
mailing list