Re: fcntl(F GETLEASE) semantics??

["Michael Kerrisk" <mtk-lkml@gmx.net>]

Trond,

> Von: Trond Myklebust <trond.myklebust@fys.uio.no>
>
> to den 11.08.2005 Klokka 14:27 (+0200) skreiv Michael Kerrisk:
> > 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.
> 
> Then what do you think that leases are supposed to do, and why?

As noted already, I don't know much of CIFS and SAMBA.
But are you saying that it is sensible and consistent that
"a process can open a file read-write, and can't place a 
read lease, but can place a write lease"?  

> An exclusive (i.e. write) lease should mean that _nothing_ other than
> your process is accessing the file. A client may cache the file data,
> metadata and read/write locks because nobody else can change that
> information, and nobody else holds locks on the file. It may also cache
> file acl/access information, and hence cache new OPEN calls.
> 
> A shared (i.e. read) lease means that there are currently no processes
> that can change the data or metadata (including your own). 
                                        ^^^^^^^^^^^^^^^^^

This is precisely the point of the problem.  Stephen 
Rothwell, and Matthew Wilcox seem to be saying that
the last bit is not the case.  

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@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/