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. Thanks, Amir.
