All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael Kerrisk" <mtk-lkml@gmx.net>
To: "J. Bruce Fields" <bfields@fieldses.org>
Cc: michael.kerrisk@gmx.net, sfr@canb.auug.org.au,
	heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org,
	andros@citi.umich.edu, matthew@wil.cx, schwidefsky@de.ibm.com
Subject: Re: fcntl: F_SETLEASE/F_RDLCK question
Date: Tue, 31 May 2005 17:41:51 +0200 (MEST)	[thread overview]
Message-ID: <18351.1117554111@www82.gmx.net> (raw)
In-Reply-To: 20050531152328.GC22433@fieldses.org

Bruce,

> On Tue, May 31, 2005 at 04:53:50PM +0200, Michael Kerrisk wrote:
> > I applied this against 2.6.12-rc4, and it fixes the problem 
> > (and I've also teasted various other facets of file leases 
> > and this change causes no obvious breakage elsewhere).
> > 
> > Are you going to push this fix into 2.6.12?
> 
> Are you sure this is actually a problem?
> 
> I still have the following questions I had before:
> 
> > I'm a little confused as to why anyone would have the expectation
> > that read leases would not conflict with write opens by the same
> > process, given that break_lease() has never functioned that way, so
> > later write opens by the same process have always broken any read 
> > lease.
> >
> > Are there applications that actually depend on the old behaviour?  Is
> > there any documentation that blesses it?  All I can find is the fcntl
> > man page, and as far as I can tell an implementation that makes read
> > leases conflict with all write opens (by the same process or not) is
> > consistent with that man page.

I believe it is still a problem: primarily because it broke
old behavior for no apparent reason (Stephen Rothwell, who was 
one of the original implementers seems to agree, since he 
suggested that one line patch).  I suspect the change was 
unintentional.

By the way, I wrote the text in the fcntl() man page
by looking at the code and experimenting.  There was no 
existing documentation of F_SETLEASE.  I'm questioning 
the change based on my understanding of how things should 
work (I didn't happen to write up this point because it 
seemed self-evident *to me*); however, I know rather 
little of the workings of SAMBA.

Cheers,

Michael

-- 
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

  reply	other threads:[~2005-05-31 15:41 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-02  9:15 fcntl: F_SETLEASE/F_RDLCK question Heiko Carstens
2005-05-02 11:04 ` Stephen Rothwell
2005-05-02 12:10   ` Heiko Carstens
2005-05-03 10:00   ` Michael Kerrisk
2005-05-03 13:14     ` Stephen Rothwell
2005-05-03 13:55       ` William A.(Andy) Adamson
2005-05-03 13:59         ` Matthew Wilcox
2005-05-03 14:15           ` William A.(Andy) Adamson
2005-05-03 14:50             ` Michael Kerrisk
2005-05-03 16:21               ` William A.(Andy) Adamson
2005-05-03 16:36                 ` J. Bruce Fields
2005-05-31 14:53       ` Michael Kerrisk
2005-05-31 15:23         ` J. Bruce Fields
2005-05-31 15:41           ` Michael Kerrisk [this message]
2005-05-31 15:34       ` File leases and fork() Michael Kerrisk

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=18351.1117554111@www82.gmx.net \
    --to=mtk-lkml@gmx.net \
    --cc=andros@citi.umich.edu \
    --cc=bfields@fieldses.org \
    --cc=heiko.carstens@de.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=michael.kerrisk@gmx.net \
    --cc=schwidefsky@de.ibm.com \
    --cc=sfr@canb.auug.org.au \
    /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.