From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx2.suse.de ([195.135.220.15]:38566 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751524AbdJaQKK (ORCPT ); Tue, 31 Oct 2017 12:10:10 -0400 Date: Tue, 31 Oct 2017 17:10:08 +0100 From: Jan Kara To: Amir Goldstein Cc: Jan Kara , linux-fsdevel , Greg KH Subject: Re: [PATCH 2/2] fsnotify: Protect bail out path of fsnotify_add_mark_locked() properly Message-ID: <20171031161008.GD26128@quack2.suse.cz> References: <20171031093342.25216-1-jack@suse.cz> <20171031093342.25216-3-jack@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Tue 31-10-17 14:26:35, Amir Goldstein wrote: > On Tue, Oct 31, 2017 at 11:33 AM, Jan Kara 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 > > Reviewed-by: Amir Goldstein > > 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? Similarly as with patch 1, I don't think real users can hit this (and even if they could, I doubt it would have any negative impact). So bothering stable with this is just a waste of resources... It falls under the "theoretical race condition" cathegory which is explicitely forbidden from stable. Honza -- Jan Kara SUSE Labs, CR