[PATCH] locks: breaking read lease should not block read open

[J. Bruce Fields]

On Thu, Jul 28, 2011 at 10:27:58PM -0400, J. Bruce Fields wrote:
> On Thu, Jul 21, 2011 at 12:35:20PM -0400, J. Bruce Fields wrote:
> > On Wed, Jul 20, 2011 at 05:15:42PM -0700, Jeremy Allison wrote:
> > > On Wed, Jul 20, 2011 at 08:07:58PM -0400, J. Bruce Fields wrote:
> > > > So it's a question about the protocols samba implements:
> > > > 
> > > > 	- Do they allow an atomic downgrade from an exclusive to a
> > > > 	  shared oplock?  (Or to a level 2 oplock, or whatever the right
> > > > 	  term is).
> > > 
> > > Yes. Exclusive can go to level 2 - in fact that's the default
> > > downgrade we do (unless an smb.conf option explicity denies it).
> > > 
> > > > 	- If so, can that happen as a response to a conflicting open?
> > > > 	  (So, if you're holding an exclusive oplock, and a conflicting
> > > > 	  open comes in, can the server-to-client break message say "now
> > > > 	  you're getting a shared oplock instead"?  Or is the client
> > > > 	  left without any oplock until it requests a new one?)
> > > 
> > > Yes, this can happen.
> > > 
> > > In SMB, we only break to no lease when a write request comes
> > > in on a exclusive or level2 oplock (read-lease) handle.
> > 
> > Ok, thanks, that means we need a more complicated fix here--I'll work on
> > that....
> 
> My attempt follows.  Lightly tested.
> 
> I'll probably try writing a test or two for it, then queueing up
> something like this for 3.2, absent objections.

Second take follows, this time after a little more testing
(lease_tests.c from git://linux-nfs.org/~bfields/lock-tests.git), some
bug fixes, and minor simplification of the logic.  This is what I intend
to queue up for 3.2.

--b.