From: Eric Paris <eparis@redhat.com>
To: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [PATCH] fanotify: dont destroy mark when ignore mask is cleared
Date: Tue, 30 Nov 2010 11:19:39 -0500 [thread overview]
Message-ID: <1291133979.3169.2.camel@localhost.localdomain> (raw)
In-Reply-To: <20101130155951.GB4814@lsanfilippo.unix.rd.tt.avira.com>
On Tue, 2010-11-30 at 16:59 +0100, Lino Sanfilippo wrote:
> On Tue, Nov 30, 2010 at 01:16:35PM +0100, Lino Sanfilippo wrote:
>
> > 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
>
> IMHO the right thing to serialize this would be to do
>
> LOCK(groups->mark_lock)
> - get the inode mark
> - set the marks mask
> - possibly destroy the mask
> UNLOCK(groups->mark_lock)
>
> But we cant do this since setting the marks mask requires the lock of the mark
> - which would mean an incorrect lock order according to fsnotify_add_mark():
>
> mark->lock
> group->mark_lock
> inode->i_lock
>
> What we could do very easily is use another mutex instead (use an existing one like the
> groups notification_mutex, or a completely new one) which is responsible for synchronising
> add_mark()/remove_mark().
I'd think a new per group mutex would be the right way to go. I'm not
sure how I feel about notification_mutex. I guess you can go ahead and
overload it and we can split it off later if someone finds it to be a
performance blocker.
-Eric
next prev parent reply other threads:[~2010-11-30 16:19 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20101130121635.277910@gmx.net>
2010-11-30 15:59 ` [PATCH] fanotify: dont destroy mark when ignore mask is cleared Lino Sanfilippo
2010-11-30 16:19 ` Eric Paris [this message]
2010-11-22 17:52 Lino Sanfilippo
2010-11-23 19:51 ` Eric Paris
2010-11-24 12:31 ` Lino Sanfilippo
2010-11-29 20:45 ` Eric Paris
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1291133979.3169.2.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=LinoSanfilippo@gmx.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.