From: Mike Waychison <Michael.Waychison@Sun.COM>
To: Ian Kent <raven@themaw.net>
Cc: Kernel Mailing List <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@osdl.org>, Maneesh Soni <maneesh@in.ibm.com>,
Al Viro <viro@parcelfarce.linux.theplanet.co.uk>,
Jeremy Fitzhardinge <jeremy@goop.org>,
"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 4/8] autofs4-2.6 - to support autofs 4.1.x
Date: Wed, 28 Jan 2004 20:27:03 -0500 [thread overview]
Message-ID: <40186167.6040608@sun.com> (raw)
In-Reply-To: <Pine.LNX.4.44.0401290832020.16657-100000@wombat.indigo.net.au>
Ian Kent wrote:
>On Wed, 28 Jan 2004, Mike Waychison wrote:
>
>
>
>>raven@themaw.net wrote:
>>
>>
>>
>>>Patch:
>>>
>>>4-autofs4-2.6.0-test9-waitq2.patch
>>>
>>>Adds a spin lock to serialize access to wait queue in the super block info
>>>struct.
>>>
>>>
>>>
>>>
>>>
>>A while back I wrote up a patch for autofs3 that serialized waitq access
>>and changed the waitq counters to atomic_t. I never sent it out because
>>I had realized that the changes I made weren't needed as all waitq
>>code-paths were running under the BKL (the big ones were ->lookup and
>>the ioctls).
>>
>>
>
>My understanding is that this code can be reached at least via lookup,
>readdir and revalidate. I thought that in 2.6 none of these held the BKL
>on entry (I'll have to check). Certainly this is the case for revalidate.
>
>
>
>
I just took a look at the autofs4 code and the BKL is explicitly held in
the lookup code. It is also implicitly held in the ioctl code.
My understanding is that when the dcache (and subsequently
->d_revalidate) was introduced into the Linux kernel, autofs3 was
modified to do revalidates, and would have had it's lock_kernel calls
added then. If autofs4 had forked off before the dcache addition, it
wouldn't have picked the lock_kernel in d_revalidate.
Peter/Jeremy, could you confirm this?
--
Mike Waychison
Sun Microsystems, Inc.
1 (650) 352-5299 voice
1 (416) 202-8336 voice
mailto: Michael.Waychison@Sun.COM
http://www.sun.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
NOTICE: The opinions expressed in this email are held by me,
and may not represent the views of Sun Microsystems, Inc.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
prev parent reply other threads:[~2004-01-29 1:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-28 15:39 [PATCH 4/8] autofs4-2.6 - to support autofs 4.1.x raven
2004-01-28 17:04 ` Mike Waychison
2004-01-29 0:35 ` Ian Kent
2004-01-29 1:27 ` Mike Waychison [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=40186167.6040608@sun.com \
--to=michael.waychison@sun.com \
--cc=akpm@osdl.org \
--cc=hpa@zytor.com \
--cc=jeremy@goop.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maneesh@in.ibm.com \
--cc=raven@themaw.net \
--cc=viro@parcelfarce.linux.theplanet.co.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