From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail.linuxfoundation.org ([140.211.169.12]:33556 "EHLO
        mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751795AbdJaNkL (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Tue, 31 Oct 2017 09:40:11 -0400
Date: Tue, 31 Oct 2017 14:40:24 +0100
From: Greg KH <gregkh@linuxfoundation.org>
To: Amir Goldstein <amir73il@gmail.com>
Cc: Jan Kara <jack@suse.cz>,
        linux-fsdevel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 2/2] fsnotify: Protect bail out path of
 fsnotify_add_mark_locked() properly
Message-ID: <20171031134024.GA2454@kroah.com>
References: <20171031093342.25216-1-jack@suse.cz>
 <20171031093342.25216-3-jack@suse.cz>
 <CAOQ4uxihykkEa87Q1W6mO80M0YY4adNyeOmSpx29X9Pi2VA1HQ@mail.gmail.com>
 <20171031125027.GA28988@kroah.com>
 <CAOQ4uxiTohOnJnhioFkFvE6qhywDxakC2QVfOJuUeFdFL2QibA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAOQ4uxiTohOnJnhioFkFvE6qhywDxakC2QVfOJuUeFdFL2QibA@mail.gmail.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

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@linuxfoundation.org> 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@suse.cz> 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@suse.cz>
> >>
> >> Reviewed-by: Amir Goldstein <amir73il@gmail.com>
> >>
> >> 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...