mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michael Kerrisk" <mtk-lkml@gmx.net>
To: Trond Myklebust <trond.myklebust@fys.uio.no>
Cc: peterc@gelato.unsw.edu.au, linux-kernel@vger.kernel.org,
	sfr@canb.auug.org.au, matthew@wil.cx, michael.kerrisk@gmx.net
Subject: Re: fcntl(F GETLEASE) semantics??
Date: Thu, 11 Aug 2005 14:27:24 +0200 (MEST)	[thread overview]
Message-ID: <24699.1123763244@www9.gmx.net> (raw)
In-Reply-To: <1123761105.8251.10.camel@lade.trondhjem.org>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 2990 bytes --]

> Von: Trond Myklebust <trond.myklebust@fys.uio.no>
> to den 11.08.2005 Klokka 10:14 (+0200) skreiv Michael Kerrisk:
> 
> > No.  The behavior in Linux recently, and arbitrarily (IMO) changed:
> 
> The change was NOT arbitrary. 

Okay -- I'm puzzled.  Two of the people that I understand to have
had a strong interest in file leases seemed to think the change 
shouldn't have occurred:

Stephen Rothwell: 
http://marc.theaimsgroup.com/?l=linux-kernel&m=111512619520116&w=2

    Thanks for the testing.  My expectation is that it shouldn't 
    matter how the current process opened the file for either 
    type of lease.  However, you are right (IMHO) that the current 
    process should *not* be counted as a writer in the case of 
    trying to obtain a F_RDLCK lease.

And Stephen suggested a one line patch to fix the problem

Matthew Wilcox also wrote:
http://marc.theaimsgroup.com/?l=linux-kernel&m=111512898520775&w=2

    On Tue, May 03, 2005 at 09:55:42AM -0400, William A.(Andy) 
    Adamson wrote:
    > i believe the current implementation is correct. opening a 
    > file for write means that you can not have a read lease, 
    > caller included.

    Why not?  Certainly, others will not be able to take out a 
    read lease, so there's very little point to only having a 
    read lease, but I don't see why we should deny it.

(By the way, I wrote the fcntl.2 manpage text for file 
leases -- because there was no existing documentation, or 
specification of the desired behavior; the text was based 
on my experiments, and some email discussions with Stephen 
Rothwell.)

And I pointed out that the existing behaviour (which is 
still current in 2.6.13-rc4) is inconsistent:

http://marc.theaimsgroup.com/?l=linux-kernel&m=111511455406623&w=2

    Some further testing showed the following (both open() 
    and fcntl(F_SETLEASE) from same process):

     open()  |  lease requested
      flag   | F_RDLCK  | F_WRLCK
    ---------+----------+----------
    O_RDONLY | okay     |  okay
    O_WRONLY | EAGAIN   |  okay
    O_RDWR   | EAGAIN   |  okay

In other words, a process can open a file read-write, and
can't place a read lease, but can place a write lease!  
That does not seem to make any sense to me.

> It was deliberate and for the reasons
> stated.

Can you elaborate -- which reasons are you referring to?  

> The whole point of leases is to support CIFS oplocks for Samba and NFSv4
> delegations in the kernel. 

Yep, I understand that much.

> Both have the same specific expected
> behaviour.
> The original deviates from that expected behaviour by allowing you to
> get a shared lease when in a condition that does not allow actual
> sharing.

And I should add -- I know little about SAMBA or CIFS.  But from 
what I've seen (the quoted messages above), the change seems to 
have been accidental, and inconsistent.

Cheers,

Michael

-- 
5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail
+++ GMX - die erste Adresse für Mail, Message, More +++

  reply	other threads:[~2005-08-11 12:27 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-08-10 23:48 fcntl(F_GETLEASE) semantics?? Peter Chubb
2005-08-11  1:14 ` Trond Myklebust
2005-08-11  1:29   ` Peter Chubb
2005-08-11  8:14     ` fcntl(F GETLEASE) semantics?? Michael Kerrisk
2005-08-11 11:51       ` Trond Myklebust
2005-08-11 12:27         ` Michael Kerrisk [this message]
2005-08-11 12:49           ` Trond Myklebust
2005-08-11 13:22             ` Michael Kerrisk
2005-08-11 14:06               ` Trond Myklebust
2005-08-11 14:12                 ` Trond Myklebust
2005-08-11 14:20                 ` J. Bruce Fields
2005-08-11 14:42                   ` Michael Kerrisk
2005-08-11 14:40                 ` Michael Kerrisk
2005-08-11 15:06                   ` Trond Myklebust
2005-08-11 15:25                     ` Trond Myklebust
2005-08-11 14:10               ` Stephen Rothwell
2005-08-11 18:41 ` fcntl(F_GETLEASE) semantics?? Heikki Orsila
2005-08-11 18:56   ` Trond Myklebust
2005-08-11 19:02     ` Heikki Orsila
2005-08-11 19:15       ` Trond Myklebust
2005-08-11 19:23         ` Heikki Orsila
2005-08-11 19:31           ` 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=24699.1123763244@www9.gmx.net \
    --to=mtk-lkml@gmx.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=michael.kerrisk@gmx.net \
    --cc=peterc@gelato.unsw.edu.au \
    --cc=sfr@canb.auug.org.au \
    --cc=trond.myklebust@fys.uio.no \
    /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®