From: Jeff Moyer <jmoyer@redhat.com>
To: Ian Kent <raven@themaw.net>
Cc: Andrew Morton <akpm@osdl.org>,
autofs mailing list <autofs@linux.kernel.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [autofs] [PATCH] autofs4: deadlock during create
Date: Tue, 14 Aug 2007 10:17:45 -0400 [thread overview]
Message-ID: <x49mywuci9i.fsf@segfault.boston.devel.redhat.com> (raw)
In-Reply-To: <1187087280.4963.18.camel@raven.themaw.net> (Ian Kent's message of "Tue\, 14 Aug 2007 18\:28\:00 +0800")
Ian Kent <raven@themaw.net> writes:
> Hi,
>
> Due to inconsistent locking in the VFS between calls to lookup and
> revalidate deadlock can occur in the automounter.
>
> The inconsistency is that the directory inode mutex is held for both
> lookup and revalidate calls when called via lookup_hash whereas it is
> held only for lookup during a path walk. Consequently, if the mutex
> is held during a call to revalidate autofs4 can't release the mutex
> to callback the daemon as it can't know whether it owns the mutex.
>
> This situation happens when a process tries to create a directory
> within an automount and a second process also tries to create the
> same directory between the lookup and the mkdir. Since the first
> process has dropped the mutex for the daemon callback, the second
> process takes it during revalidate leading to deadlock between the
> autofs daemon and the second process when the daemon tries to create
> the mount point directory.
>
> After spending quite a bit of time trying to resolve this on more than
> one occassion, using rather complex and ulgy approaches, it turns out
> that just delaying the hashing of the dentry until the create operation
> work fine.
>
> Signed-off-by: Ian Kent <raven@themaw.net>
Acked-by: Jeff Moyer <jmoyer@redhat.com>
-Jeff
next prev parent reply other threads:[~2007-08-14 14:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-14 10:28 Ian Kent
2007-08-14 14:17 ` Jeff Moyer [this message]
2007-08-15 6:31 ` [autofs] " Ian Kent
2007-08-17 3:56 ` Ian Kent
2007-08-17 6:54 ` Andrew Morton
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=x49mywuci9i.fsf@segfault.boston.devel.redhat.com \
--to=jmoyer@redhat.com \
--cc=akpm@osdl.org \
--cc=autofs@linux.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=raven@themaw.net \
/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®