Re: fcntl(F GETLEASE) semantics??

[Michael Kerrisk]

> Von: Peter Chubb <peterc@xxxxxxxxxxxxxxxxxx>
> 
> >>>>> "Trond" == Trond Myklebust <trond.myklebust@xxxxxxxxxx> writes:
> 
> Trond> to den 11.08.2005 Klokka 09:48 (+1000) skreiv Peter Chubb:
> >> Hi, The LTP test fcntl23 is failing.  It does, in essence, fd =
> >> open(xxx, O_RDWR|O_CREAT, 0777); if (fcntl(fd, F_SETLEASE, F_RDLCK)
> >> == -1) fail;
> >> 
> >> fcntl always returns EAGAIN here.  The manual page says that a read
> >> lease causes notification when `another process' opens the file for
> >> writing or truncates it.  The kernel implements `any process'
> >> (including the current one).
> >> 
> >> Which semantics are correct?  Personally I think that what the
> >> kernel implements is correct (you can't get a read lease unsless
> >> there are no writers _at_ _all_)
> 
> Trond> A read lease should mean that there are no writers at all.
> 
> Trond> If we were to allow the current process to open for write, then
> Trond> that would still mean that nobody else can get a lease. In
> Trond> effect you have been granted a lease with exclusive semantics
> Trond> (i.e. a write lease). You might as well request that instead of
> Trond> pretending it is a read lease.
> 
> So the manual page is wrong.  Fine.

No.  The behavior in Linux recently, and arbitrarily (IMO) changed:

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

One of the developers of the file leases mechanism seems to have 
agreed that this change should not have occurred:

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

but the suggested patch did not (yet) make its way into the kernel.

Stephen -- what is your take on this now?

Cheers,

Michael

-- 
GMX DSL = Maximale Leistung zum minimalen Preis!
2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/