From: "J. Bruce Fields" <bfields@fieldses.org>
To: Pavel Emelyanov <xemul@openvz.org>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
devel@openvz.org
Subject: Re: [PATCH] Wake up mandatory locks waiter on chmod
Date: Wed, 19 Sep 2007 14:07:49 -0400 [thread overview]
Message-ID: <20070919180749.GD5946@fieldses.org> (raw)
In-Reply-To: <46EF71F0.9010606@openvz.org>
On Tue, Sep 18, 2007 at 10:36:32AM +0400, Pavel Emelyanov wrote:
> J. Bruce Fields wrote:
> > I would also prefer a locking scheme that didn't rely on the BKL. That
> > said, except for this race:
>
> I would as well :) But I don't know the locking code good enough to
> start fixing. Besides, even if I send a patch series that handles this,
> I don't think that anyone will accept it, due to "this changes too much
> code", "can you prove you fixed all the places" and so on...
Several people have expressed interest in a locking scheme for locks.c
(and probably lockd) that doesn't depend on BKL, so I don't think it
would be ignored. But, yes, it would have to be done very carefully;
there have been at least one or two previous attempts that failed.
> >>> (For example, my impression is that a mandatory lock can be applied just
> >>> after the locks_mandatory_area() checks but before the io actually
> >>> completes.)
> >
> > ... I'm not aware of other races in the existing file-locking code. It
> > sounds like you might be. Could you give specific examples?
>
> Well, there's a long standing BUG in leases code - when we made all the
> checks in inserting lease, we call the locks_alloc_lock() and may fall
> asleep. Bu after the wakeup nobody re-checks for the things to change.
Ouch, yes, you're right.
> I suspect there are other bad places.
OK. Thanks in advance for finding any!
--b.
next prev parent reply other threads:[~2007-09-19 18:08 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-13 14:30 [PATCH] Wake up mandatory locks waiter on chmod Pavel Emelyanov
2007-09-16 19:41 ` J. Bruce Fields
2007-09-17 6:37 ` Pavel Emelyanov
2007-09-17 14:59 ` J. Bruce Fields
2007-09-18 6:36 ` Pavel Emelyanov
2007-09-19 18:07 ` J. Bruce Fields [this message]
2007-09-19 18:16 ` Trond Myklebust
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=20070919180749.GD5946@fieldses.org \
--to=bfields@fieldses.org \
--cc=devel@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=xemul@openvz.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 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.