On Tue, Oct 31, 2017 at 02:57:49PM +0200, Amir Goldstein wrote: > On Tue, Oct 31, 2017 at 2:50 PM, Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> wrote: > > On Tue, Oct 31, 2017 at 02:26:35PM +0200, Amir Goldstein wrote: > >> On Tue, Oct 31, 2017 at 11:33 AM, Jan Kara <jack@xxxxxxx> wrote: > >> > When fsnotify_add_mark_locked() fails it cleans up the mark it was > >> > adding. Since the mark is already visible in group's list, we should > >> > protect update of mark->flags with mark->lock. I'm not aware of any real > >> > issues this could cause (since we also hold group->mark_mutex) but > >> > better be safe and obey locking rules properly. > >> > > >> > Signed-off-by: Jan Kara <jack@xxxxxxx> > >> > >> Reviewed-by: Amir Goldstein <amir73il@xxxxxxxxx> > >> > >> IMO, even though this does not fix a concrete bug, if it's worth > >> fixing in upstream, it's worth fixing in stable. > >> A future stable fix may either make this into a concrete bug > >> or just be harder to apply. > >> > >> So I suggest to add the Fixes: and Cc: stable tags. > >> > >> Greg, > >> > >> Do you agree with this reasoning? > > > > If it doesn't fix an actual bug, how does that fit with the stable > > kernel rules? > > > > So this is the case of incorrect code w.r.t locking rules > that either does not hit a bug because of an indirect protection > (as Jan wrote in commit) or we did not find how to hit a bug. > > Not sure how you want to call this, but if you think it doesn't belong > for stable we won't send it. That's why I called for your opinion. How about we get the opinion of the developer and maintainer of the subsystem, I will defer to them...
