mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Michael Kerrisk" <mtk-lkml@gmx.net>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org,
	andros@citi.umich.edu, matthew@wil.cx, schwidefsky@de.ibm.com,
	michael.kerrisk@gmx.net
Subject: Re: fcntl: F_SETLEASE/F_RDLCK question
Date: Tue, 3 May 2005 12:00:18 +0200 (MEST)	[thread overview]
Message-ID: <2606.1115114418@www14.gmx.net> (raw)
In-Reply-To: <20050502210411.06226103.sfr@canb.auug.org.au>

Hi Stephen,

> On Mon, 2 May 2005 11:15:24 +0200 Heiko Carstens
> <heiko.carstens@de.ibm.com> wrote:
> >
> > the semantics of fnctl used together with F_SETLEASE and
> > argument F_RDLCK have been changed with bk changeset
> > 1.1938.185.141 (sometime between 2.6.9 and 2.6.10).
> > Since then it's only possible to get a read lease when the
> > file in question does not have _any_ writers.
> > This is at least inconsistent with the man page of fcntl
> > and looks pretty much like this is a bug in the kernel.
> > 
> > Any comments?
> 
> The previous behaviour was a bug that occurred because at the time the
> original lease code was written, it was not possible to tell if there 
> were
> writers when the read lease was being taken. Further improvements in the
> kernel have since made this possible.
> 
> The intention of a read lease is to let the holder know is anyone tries 
> to modify the file.
> 
> The current behaviour does not conflict with the man pages on Debian
> (although the previous behaviour did not either :-))

Indeed the problem referred to is fixed, but it looks like another 
one may have been introduced.

It now appears (I tested on 2.6.11.6) that if a process opens 
a file O_RDWR and then tries to place a read lease via that
file descriptor, then the F_SETLEASE fails with EAGAIN, 
even though no other process has the file open for writing.  
(On the other hand, if the process opens the file 
O_WRONLY, then it can place either a read or a write lease.  
This is how I think things always worked, but it seems 
inconsistent with the aforementioned behaviour.)  

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

This seems strange (I imagine the caller should be excluded 
from the list of processes being checked to see if the file 
is opened for writing), and differs from earlier kernel
versions.  What is the intended behaviour here?

Cheers,

Michael

-- 
+++ Lassen Sie Ihren Gedanken freien Lauf... z.B. per FreeSMS +++
GMX bietet bis zu 100 FreeSMS/Monat: http://www.gmx.net/de/go/mail

  parent reply	other threads:[~2005-05-03 10:00 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-05-02  9:15 Heiko Carstens
2005-05-02 11:04 ` Stephen Rothwell
2005-05-02 12:10   ` Heiko Carstens
2005-05-03 10:00   ` Michael Kerrisk [this message]
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
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=2606.1115114418@www14.gmx.net \
    --to=mtk-lkml@gmx.net \
    --cc=andros@citi.umich.edu \
    --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 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®