From: Ian Kent <raven@themaw.net>
To: Avi Kivity <avi@redhat.com>
Cc: Arnd Bergmann <arnd@arndb.de>,
autofs@linux.kernel.org,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: autofs4 hang in 2.6.37-rc1
Date: Mon, 15 Nov 2010 09:45:33 +0800 [thread overview]
Message-ID: <1289785533.3248.18.camel@localhost> (raw)
In-Reply-To: <4CE00194.3070601@redhat.com>
On Sun, 2010-11-14 at 17:34 +0200, Avi Kivity wrote:
> On 11/14/2010 05:15 PM, Arnd Bergmann wrote:
> > On Sunday 14 November 2010 14:51:04 Avi Kivity wrote:
> > > automount S ffff88012a28a680 0 399 1 0x00000000
> > > ffff88012a07bd08 0000000000000082 0000000000000000 0000000000000000
> > > ffff88012a07a010 ffff88012a07bfd8 0000000000011800 ffff88012693c260
> > > ffff88012693c5d0 ffff88012693c5c8 0000000000011800 0000000000011800
> > > Call Trace:
> > > [<ffffffff81056197>] ? prepare_to_wait+0x67/0x74
> > > [<ffffffff811b23eb>] autofs4_wait+0x5a4/0x6d5
> > > [<ffffffff81055f25>] ? autoremove_wake_function+0x0/0x34
> > > [<ffffffff811b2ba5>] autofs4_do_expire_multi+0x5b/0xa3
> > > [<ffffffff811b2c39>] autofs4_expire_multi+0x4c/0x54
> > > [<ffffffff811b1750>] autofs4_root_ioctl_unlocked+0x23e/0x252
> > > [<ffffffff811b1808>] autofs4_root_ioctl+0x39/0x53
> > > [<ffffffff810f5e5c>] do_vfs_ioctl+0x557/0x5bb
> > > [<ffffffff810ca644>] ? remove_vma+0x6e/0x76
> > > [<ffffffff810cb6a2>] ? do_munmap+0x31c/0x33e
> > > [<ffffffff810f5f02>] sys_ioctl+0x42/0x65
> > > [<ffffffff81002b42>] system_call_fastpath+0x16/0x1b
> > >
> > >
> > > Shouldn't we drop autofs4_ioctl_mutex while we wait?
> >
> > If the ioctl can sleep for multiple seconds, the mutex should
> > indeed be dropped, and that would be safe because we used to
> > do the same with the BKL.
> >
> > The question is why this would sleep for more than 120 seconds.
> >
>
> Let's fix first and ask questions later.
You can't hold an exclusive mutex during an autofs expire because the
daemon will start by calling the ioctl to check for a dentry to expire
then call back to the daemon to perform the umount and wait for a status
return (also an ioctl).
>From memory the expire is the only ioctl that is sensitive to this
deadlock.
So, either the mutex must be released while waiting for the status
return or get rid of the autofs4_ioctl_mutex altogether.
Ian
next prev parent reply other threads:[~2010-11-15 1:45 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-14 12:55 autofs4 hang in 2.6.37-rc1 Avi Kivity
2010-11-14 13:51 ` Avi Kivity
2010-11-14 15:15 ` Arnd Bergmann
2010-11-14 15:34 ` Avi Kivity
2010-11-15 1:45 ` Ian Kent [this message]
2010-11-15 8:54 ` Arnd Bergmann
2010-11-15 13:22 ` Ian Kent
2010-11-15 13:27 ` Avi Kivity
2010-11-15 13:38 ` Ian Kent
2010-11-15 13:42 ` Ian Kent
2010-11-18 3:54 ` Ian Kent
2010-11-25 13:17 ` Arnd Bergmann
2010-11-15 1:31 ` Ian Kent
2010-11-15 9:02 ` Avi Kivity
2010-11-22 8:42 ` Thomas Fjellstrom
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=1289785533.3248.18.camel@localhost \
--to=raven@themaw.net \
--cc=arnd@arndb.de \
--cc=autofs@linux.kernel.org \
--cc=avi@redhat.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;
as well as URLs for NNTP newsgroup(s).