Date: Tue, 3 May 2005 16:50:13 +0200 (MEST)
From: "Michael Kerrisk" <michael.kerrisk@gmx.net>
To: "William A.(Andy) Adamson" <andros@citi.umich.edu>
Cc: matthew@wil.cx, andros@citi.umich.edu, sfr@canb.auug.org.au,
       mtk-lkml@gmx.net, heiko.carstens@de.ibm.com,
       linux-kernel@vger.kernel.org, schwidefsky@de.ibm.com,
       andros@citi.umich.edu
MIME-Version: 1.0
References: <20050503141552.F42371BAD1@citi.umich.edu>
Subject: Re: fcntl: F_SETLEASE/F_RDLCK question
Message-ID: <5531.1115131813@www41.gmx.net>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1462
Lines: 42

> > 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 definition: a read lease means there are no writers. so, the question
> is 
> not 'why not', the question is why? why hand out a read lease to an open
> for write?

Andy,

Look more closely at my earlier table. 

Regardless of what the answer to your question is, the 
current semantics are bizarre.  As things stand, a process
can open a file O_RDWR, and and can place a WRITE lease 
but not a READ lease.  That can't be right.

FWIW it's worth, I think the read lease should be allowed.
Oplocks are concerned with what other processes are doing, 
not what the caller is doing.  Also, the current semantcis
break backward compatibility.

Cheers,

Michael

-- 
+++ Neu: Echte DSL-Flatrates von GMX - Surfen ohne Limits +++
Always online 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/