From: Rob Gardner <rob.gardner@hp.com>
To: Tom Talpey <tmtalpey@gmail.com>
Cc: "J. Bruce Fields" <bfields@fieldses.org>,
"linux-nfs@vger.kernel.org" <linux-nfs@vger.kernel.org>
Subject: Re: Huge race in lockd for async lock requests?
Date: Fri, 29 May 2009 09:24:25 -0600 [thread overview]
Message-ID: <4A1FFE29.2060306@hp.com> (raw)
In-Reply-To: <4a1fe1c0.06045a0a.165b.5fbc-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
Tom Talpey wrote:
> At 10:59 PM 5/28/2009, Rob Gardner wrote:
>
>> J. Bruce Fields wrote:
>>
>>> Looking at the code.... This is all under the BKL, and as far as I can
>>> tell there aren't any blocking operations anywhere there, so I don't
>>> think this should happen if the filesystem is careful. Have you seen it
>>> happen?
>>>
>> Aha, I just figured it out and you were right. The filesystem in this
>> case was not careful. It broke the rules and actually made the fl_grant
>> call *before* even returning to nlmsvc_lock's call to vfs_lock_file, and
>> it did it in the lockd thread! So the BKL was of no use, and I saw
>> nlmsvc_grant_deferred print "grant for unknown block". So I think
>> everything is ok, no huge race in lockd for async lock requests. Thank
>> you for clearing this up.
>>
>
> Gack! I'm surprised it worked at all. The fact that the BKL allows itself to
> be taken recursively really masked your filesystem bug. If the BKL had
> blocked, or asserted, the bug would never have happened.
>
Yeah, recall that I'm using a very old kernel (circa 2.6.18) which I
think must still allow the BKL to be acquired recursively.
> This is as good a time as any to point out that the BKL's use in the lockd
> code is insidious and needs some serious attention.
No disagreement here! I think I almost understand enough about lockd to
remove the BKL, but the operative word there is "almost".
Rob Gardner
next prev parent reply other threads:[~2009-05-29 15:24 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-15 14:48 Virtual IPs and blocking locks Sachin S. Prabhu
2009-05-15 16:50 ` Rob Gardner
2009-05-18 13:41 ` Sachin S. Prabhu
2009-05-18 13:46 ` Trond Myklebust
2009-05-18 13:55 ` Rob Gardner
2009-05-19 20:43 ` Huge race in lockd for async lock requests? Rob Gardner
2009-05-19 21:33 ` Tom Talpey
2009-05-20 6:55 ` Rob Gardner
2009-05-20 14:00 ` Tom Talpey
[not found] ` <4a140d0a.85c2f10a.53bc.0979-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-20 14:14 ` Tom Talpey
[not found] ` <4a14106e.48c3f10a.7ce3.0e55-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-20 23:20 ` Rob Gardner
2009-05-20 16:37 ` Rob Gardner
2009-05-28 20:05 ` J. Bruce Fields
2009-05-28 21:34 ` Rob Gardner
2009-05-29 0:26 ` J. Bruce Fields
2009-05-29 2:59 ` Rob Gardner
2009-05-29 13:22 ` Tom Talpey
[not found] ` <4a1fe1c0.06045a0a.165b.5fbc-ATjtLOhZ0NVl57MIdRCFDg@public.gmane.org>
2009-05-29 15:24 ` Rob Gardner [this message]
2009-05-29 19:14 ` J. Bruce Fields
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=4A1FFE29.2060306@hp.com \
--to=rob.gardner@hp.com \
--cc=bfields@fieldses.org \
--cc=linux-nfs@vger.kernel.org \
--cc=tmtalpey@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.