From: "J. Bruce Fields" <bfields@fieldses.org>
To: Pavel Emelyanov <xemul@openvz.org>
Cc: Trond Myklebust <trond.myklebust@fys.uio.no>,
Andrew Morton <akpm@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
devel@openvz.org
Subject: Re: [PATCH] Wake up mandatory locks waiter on chmod (v2)
Date: Tue, 18 Sep 2007 11:19:57 -0400 [thread overview]
Message-ID: <20070918151957.GA18476@fieldses.org> (raw)
In-Reply-To: <46EF7136.7080308@openvz.org>
On Tue, Sep 18, 2007 at 10:33:26AM +0400, Pavel Emelyanov wrote:
> Trond Myklebust wrote:
> > IOW: the process that is waiting in locks_mandatory_area() will be
> > released as soon as the advisory lock is dropped. If that theory is
> > broken in practice, then that is the bug that we need to fix. We neither
> > want to add a load of locking crap to notify_change(), nor should we
> > need to.
>
> We have this for inotify already. Adding wakeup for mandatory lock
> is not that bad.
>
> Anyway - I noticed, that the system state can become not consistent
> and proposed the way to fix it. If this inconsistency is not a big
> deal, and nobody cares, than I'm fine with forgetting this patch,
> since I have no other arguments to protect it, but "this is just not
> very nice without this patch".
Maybe this should be documented, e.g. in fcntl(2). I'm not sure exactly
what we'd say--we probably don't want to commit to the current behavior.
Maybe something like "behavior is undefined when setting or clearing
mandatory locking on a file while it is locked".
--b.
next prev parent reply other threads:[~2007-09-18 15:20 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-17 8:13 [PATCH] Wake up mandatory locks waiter on chmod (v2) Pavel Emelyanov
2007-09-17 13:55 ` Trond Myklebust
2007-09-17 14:16 ` Pavel Emelyanov
2007-09-17 16:00 ` Trond Myklebust
2007-09-18 6:33 ` Pavel Emelyanov
2007-09-18 15:19 ` J. Bruce Fields [this message]
2007-09-18 16:14 ` Trond Myklebust
2007-09-18 16:52 ` J. Bruce Fields
2007-09-18 16:54 ` Trond Myklebust
2007-09-18 17:40 ` J. Bruce Fields
2007-09-18 18:38 ` Hugh Dickins
2007-09-25 16:55 ` [PATCH 1/2] Documentation: move mandatory locking documentation to filesystems/ J. Bruce Fields
2007-09-25 16:56 ` [PATCH 2/2] locks: add warning about mandatory locking races J. Bruce Fields
2007-09-25 17:12 ` [PATCH 1/2] Documentation: move mandatory locking documentation to filesystems/ Randy Dunlap
2007-09-25 17:24 ` 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=20070918151957.GA18476@fieldses.org \
--to=bfields@fieldses.org \
--cc=akpm@osdl.org \
--cc=devel@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=trond.myklebust@fys.uio.no \
--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.