On Tue, Jul 17, 2018 at 5:24 PM, Miklos Szeredi <miklos@xxxxxxxxxx> wrote: > On Fri, Jul 13, 2018 at 6:05 PM, Amir Goldstein <amir73il@xxxxxxxxx> wrote: >> On Fri, Jul 13, 2018 at 6:40 PM, Jeff Layton <jlayton@xxxxxxxxxx> wrote: >>> On Fri, 2018-07-13 at 17:22 +0300, Amir Goldstein wrote: >>>> nfsd and lockd call vfs_lock_file() to lock/unlock the inode >>>> returned by locks_inode(file). >>>> >>>> Many places in nfsd/lockd code use the inode returned by >>>> file_inode(file) for lock manipulation. With Overlayfs, file_inode() >>>> (the underlying inode) is not the same object as locks_inode() (the >>>> overlay inode). This can result in "Leaked POSIX lock" messages >>>> and eventually to a kernel crash as reported by Eddie Horng: >>>> https://marc.info/?l=linux-unionfs&m=153086643202072&w=2 >>>> >>>> Fix all the call sites in nfsd/lockd that should use locks_inode(). >>>> This is a correctness bug that manifested when overlayfs gained >>>> NFS export support in v4.16. >>>> >>>> Reported-by: Eddie Horng <eddiehorng.tw@xxxxxxxxx> >>>> Tested-by: Eddie Horng <eddiehorng.tw@xxxxxxxxx> >>>> Cc: Jeff Layton <jlayton@xxxxxxxxxx> >>>> Fixes: 8383f1748829 ("ovl: wire up NFS export operations") >>>> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx> >>>> --- >>>> >>>> Hi Bruce, >>>> >>>> For the purpose of locks, nfsd/lockd should look at locks_inode() >>>> just like vfs lock functions. >>>> >>>> Hopefully, Miklos's work on stacked overlayfs file operations will >>>> be merged soon and locks_inode() will become the same as file_inode(), >>>> but we will still need this fix for stable kernels v4.16 through v4.18. > > Needs a Cc: stable@... tag then. > > Should I take this patch (based on the fact that it only affects > overlayfs exports)? > > Or will you take it, Bruce? > Bruce? Jeff? It's probably a good time for someone to put this patch in -next. Should Miklos do it? Thanks, Amir. -- To unsubscribe from this list: send the line "unsubscribe linux-unionfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html