From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Paris Subject: Re: [PATCH] fanotify: dont destroy mark when ignore mask is cleared Date: Mon, 29 Nov 2010 15:45:31 -0500 Message-ID: <1291063531.3248.30.camel@localhost.localdomain> References: <20101122175229.GC5512@lsanfilippo.unix.rd.tt.avira.com> <1290541879.1443.32.camel@localhost.localdomain> <20101124123151.GB26499@lsanfilippo.unix.rd.tt.avira.com> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org To: Lino Sanfilippo Return-path: In-Reply-To: <20101124123151.GB26499@lsanfilippo.unix.rd.tt.avira.com> Sender: linux-kernel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org On Wed, 2010-11-24 at 13:31 +0100, Lino Sanfilippo wrote: > 2. I just realized that we cant simply call destroy_mark() if the masks are 0. > There may be one or more concurrent processes calling fsnotify_find_inode_mark() > (see fanotify_add_inode_mark()) and get the mark we are about to destroy at the > same time. > > I will take a closer look at it, but it seems to be difficult to me to safely > call destroy_mark() as long as we are not in the context of fanotify_release() (in > which we dont have to deal with concurrency like that any more). I guess it is a question of safe vs racy. Yes it is safe, nothing will explode or panic. But we might have a race between one task removing an event type causing the mask to go to 0 and we should destroy the mark and another task adding an event type. If it raced just right we might destroy the mark after the second task added to it. I guess we really need to serialize fsnotify_mark() per group to solve the race... Do you want to take a stab at fixing these things or should I? -Eric