linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Lino Sanfilippo <LinoSanfilippo@gmx.de>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	Al Viro <viro@ZenIV.linux.org.uk>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	akpm@linux-foundation.org, linux-fsdevel@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH resend] audit: fix mark refcounting
Date: Thu, 15 Dec 2011 17:28:12 -0500	[thread overview]
Message-ID: <1323988092.22363.11.camel@localhost> (raw)
In-Reply-To: <20111215200631.GA2379@Neptun>

On Thu, 2011-12-15 at 21:06 +0100, Lino Sanfilippo wrote:
> On Thu, Dec 15, 2011 at 10:03:41AM +0100, Miklos Szeredi wrote:
> >  
> > +	audit_get_parent(parent);
> >  	fsnotify_destroy_mark(&parent->mark);
> > +	audit_put_parent(parent);
> 
> Hi,
> 
> What about taking an extra ref on an inode mark in send_to_group()
> before we call handle_event()?
> So we dont have to handle the cases in which a mark is destroyed
> explicitly...

Yes, but it puts atomic operations on a much hotter path.  I don't
believe there is actually a bug in the code here, but clearly we're
tripping over a BUG() I put in the code.  These patches shut up the
BUG() with minimal overhead, but don't really solve any problem.

Lino is right, the 'right' place to do this would be to take a reference
in fs/notify/fsnotify.c::fsnotify() when we find a mark under the srcu
lock and drop that reference when we are finished using that mark.
Since that function only ever uses the mark to call the handler() if it
gets destroyed in the handler that is fine.  We'd have a real bug here
if fsnotify() used the mark after the handler call...

How expensive is an atomic_inc()/atomic_dec() combo?  If it's mostly
free we can do it in the right place.

-Eric


  reply	other threads:[~2011-12-15 22:28 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-07 14:59 [PATCH] audit: fix mark refcounting Miklos Szeredi
2011-11-15 14:12 ` Miklos Szeredi
2011-11-15 14:31   ` Eric Paris
2011-12-14 14:35 ` [PATCH resend] " Miklos Szeredi
2011-12-15  2:15   ` Linus Torvalds
2011-12-15  8:40     ` Al Viro
2011-12-15  8:56       ` Miklos Szeredi
2011-12-15  9:01         ` Al Viro
2011-12-15  9:03         ` Miklos Szeredi
2011-12-15 20:06           ` Lino Sanfilippo
2011-12-15 22:28             ` Eric Paris [this message]
2011-12-15 22:34               ` Linus Torvalds
2011-12-15 22:55             ` Al Viro
2012-01-12 16:59               ` Miklos Szeredi
2011-12-15 16:48       ` Linus Torvalds
2011-12-15  8:49     ` Miklos Szeredi

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=1323988092.22363.11.camel@localhost \
    --to=eparis@redhat.com \
    --cc=LinoSanfilippo@gmx.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).