mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Ian Kent <raven@themaw.net>
To: Jeff Mahoney <jeffm@suse.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Andrew Morton <akpm@osdl.org>
Subject: Re: [PATCH] autofs4: fix race in unhashed dentry code
Date: Thu, 12 Apr 2007 02:13:09 +0800	[thread overview]
Message-ID: <1176315189.3377.35.camel@raven.themaw.net> (raw)
In-Reply-To: <461D254C.9020607@suse.com>

On Wed, 2007-04-11 at 14:13 -0400, Jeff Mahoney wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Ian Kent wrote:
> > On Thu, 2007-04-12 at 02:00 +0800, Ian Kent wrote:
> >> On Thu, 2007-04-12 at 01:49 +0800, Ian Kent wrote:
> >>> On Wed, 2007-04-11 at 11:05 -0400, Jeff Mahoney wrote:
> >>>>  Commit f50b6f8691cae2e0064c499dd3ef3f31142987f0 introduced a
> >>>>  race in autofs4 between autofs_lookup_unhashed() and
> >>>>  autofs_dentry_release().
> >>>>
> >>>>  autofs_dentry_release() ends up clearing the ->dentry and ->inode
> >>>>  members of autofs_info before removing it from the rehash list. The
> >>>>  list is protected by the rehash lock in both functions, but
> >>>>  since autofs_dentry_release() starts tearing the autofs_info struct
> >>>>  down before removing it from the list, autofs_lookup_unhashed() can
> >>>>  get a autofs_info with a NULL dentry.
> >>>>
> >>>>  This patch moves the clearing of ->dentry and ->inode after the removal
> >>>>  from the rehash list.
> >>> Oh .. excellent, I had a bug report but I just couldn't see it for
> >>> looking.
> >> Maybe I've been a bit hasty with the celebration.
> >> It looks like I've got a bigger locking problem here.
> >> If autofs4_dentry_release waits on the rehash lock and
> >> autofs4_lookup_unhashed reclaims it then the info struct and the dentry
> >> go away unconditionally as the release is called just prior to freeing
> >> the dentry memory, right?.
> > 
> > No I'm wrong, dentry_iput holds the dcache locks till it sets d_inode to
> > NULL, the point of the d_inode check in autofs4_lookup_unhashed.
> > 
> > My day is still made.
> > 
> 
> Ok, that was quick. I thought it was ok, but was about to dig back in to
> make sure. :)

Ya .. I'll think about it some more but it looks good.
Thanks again.

> 
> - -Jeff
> 
> - --
> Jeff Mahoney
> SUSE Labs
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.5 (GNU/Linux)
> Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org
> 
> iD8DBQFGHSVMLPWxlyuTD7IRArOcAKCGwXJaqObc3ee3W810zv5CU2h/MgCfbLUd
> 4dR++d9OFimkdWGYcmJvWlE=
> =+Tlm
> -----END PGP SIGNATURE-----


      reply	other threads:[~2007-04-11 18:15 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-11 15:05 Jeff Mahoney
2007-04-11 17:49 ` Ian Kent
2007-04-11 18:00   ` Ian Kent
2007-04-11 18:08     ` Ian Kent
2007-04-11 18:13       ` Jeff Mahoney
2007-04-11 18:13         ` Ian Kent [this message]

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=1176315189.3377.35.camel@raven.themaw.net \
    --to=raven@themaw.net \
    --cc=akpm@osdl.org \
    --cc=jeffm@suse.com \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®