[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20190204110339.GA19811@kroah.com>
Date: Mon, 4 Feb 2019 12:03:39 +0100
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Amir Goldstein <amir73il@...il.com>
Cc: linux-kernel <linux-kernel@...r.kernel.org>,
stable <stable@...r.kernel.org>, Jan Kara <jack@...e.cz>
Subject: Re: [PATCH 4.9 30/30] fanotify: fix handling of events on child
sub-directory
On Mon, Feb 04, 2019 at 12:48:00PM +0200, Amir Goldstein wrote:
> On Mon, Feb 4, 2019 at 12:44 PM Greg Kroah-Hartman
> <gregkh@...uxfoundation.org> wrote:
> >
> > 4.9-stable review patch. If anyone has any objections, please let me know.
> >
> > ------------------
> >
> > From: Amir Goldstein <amir73il@...il.com>
> >
> > commit b469e7e47c8a075cc08bcd1e85d4365134bdcdd5 upstream.
> >
> > When an event is reported on a sub-directory and the parent inode has
> > a mark mask with FS_EVENT_ON_CHILD|FS_ISDIR, the event will be sent to
> > fsnotify() even if the event type is not in the parent mark mask
> > (e.g. FS_OPEN).
> >
> > Further more, if that event happened on a mount or a filesystem with
> > a mount/sb mark that does have that event type in their mask, the "on
> > child" event will be reported on the mount/sb mark. That is not
> > desired, because user will get a duplicate event for the same action.
> >
> > Note that the event reported on the victim inode is never merged with
> > the event reported on the parent inode, because of the check in
> > should_merge(): old_fsn->inode == new_fsn->inode.
> >
> > Fix this by looking for a match of an actual event type (i.e. not just
> > FS_ISDIR) in parent's inode mark mask and by not reporting an "on child"
> > event to group if event type is only found on mount/sb marks.
> >
> > [backport hint: The bug seems to have always been in fanotify, but this
> > patch will only apply cleanly to v4.19.y]
> >
>
> Same comment about this backport hint being misleading in the
> context of the backport patch.
I try to leave the text in the changelog identical to what is upstream
to make it easier to track things.
thanks,
greg k-h
Powered by blists - more mailing lists