is_locked optimization

[tridge at samba.org]

Jeremy,

 > > > When reading/writing file with locking and strict locking (default)
 > > > enabled, is_locked is called. I have very little knowledge about tdb
 > > > overhead, but it seems that if oplock is granted, unnecessary (to me,)
 > > > to call brl_locktest.
 > > > Attached is a suggested change for is_locked in cases an oplock is
 > > > granted.
 > > > I would like to hear any opinion regarding this change, and of course,
 > > > if it is wrong.
 > 
 > Nope - looks a good idea to me (with some testing of course). I'll commit it
 > into the SVN for the next release !

I haven't looked at the details of the patch, but from the above
description it is not correct.

A client having an oplock and a client using byte range locks are
totally separate things. It is quite possible that a client will make
byte range locking calls that conflict with itself. This can happen
because the client supplies a "locking context" in the form of the
smbpid that affects all byte range locking calls, but does not
interact with oplocks.

As an example, a client application might be internally
multi-threaded, and might use byte range locking on files to prevent
the threads from colliding. Each of the threads would be operating on
the same open file handle, so it can be oplocked, but each could be
operating with a separate smbpid, so their locks should conflict.

At the very least please write a test that checks that the above
scenario cannot happen. I will be quite surprised if you find it is
safe to skip brl locking calls on oplocked files.

Cheers, Tridge