mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: Pavel Emelyanov <xemul@openvz.org>, 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 12:14:55 -0400	[thread overview]
Message-ID: <1190132095.6656.12.camel@heimdal.trondhjem.org> (raw)
In-Reply-To: <20070918151957.GA18476@fieldses.org>

On Tue, 2007-09-18 at 11:19 -0400, J. Bruce Fields wrote:
> 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".

The behaviour is pretty much undefined if you set/clear mandatory
locking on the file while some application has it open. It is hard to
see how you can avoid that unless you exclude simultaneous chmod,
read(), write(), and fcntl(SETLK) operations.

Note also that strictly speaking, we're not even compliant with the
System V behaviour on read() and write(). See:

  http://www.unix.org.ua/orelly/networking_2ndEd/nfs/ch11_01.htm
and
  http://docs.sun.com/app/docs/doc/801-6736/6i13fom0a?l=en&a=view&q=mandatory+lock

According to these docs, we should be wrapping each and every read() and
write() syscall with a mandatory lock. The fact that we're not, and yet
still not seeing any complaints just goes to show how few people are
actually using and relying on this...

  Trond


  reply	other threads:[~2007-09-18 16:15 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-17  8:13 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
2007-09-18 16:14           ` Trond Myklebust [this message]
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=1190132095.6656.12.camel@heimdal.trondhjem.org \
    --to=trond.myklebust@fys.uio.no \
    --cc=akpm@osdl.org \
    --cc=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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®