We have to deny a level 2 oplock if kernel oplocks are enabled
commit3c10d065247c94ceb721b102402bc6c4aeefe33d
authorVolker Lendecke <vl@samba.org>
Wed, 8 Apr 2009 06:29:23 +0000 (8 08:29 +0200)
committerVolker Lendecke <vl@samba.org>
Sun, 12 Apr 2009 12:56:23 +0000 (12 14:56 +0200)
tree44252a43c1f753f6b53d66ea172aa0d59e55d2b2
parent602059a6ab8c4939dd453566415321b2b85706f4
We have to deny a level 2 oplock if kernel oplocks are enabled

The second r/o opener of a file is supposed to get a level2 oplock. The first
opener due to the protection in process_oplock_break_message() has been forced
to break to no oplock. The second opener according to locking.tdb gets a level2
oplock. Further down in open_file_ntcreate we try to set this level2 oplock in
the kernel, and the non-clustered Linux kernel disallows this. The rules for
the kernel leases are a bit baroque, but the attempt to do the SETLEASE
correctly fails and we end up with no oplock for any client.

In the clustered case however the linux kernel on the second opening node has
not seen the open fd of the first node, it is only the cluster fs that has this
information. If the cluster fs does not have the very same notion of leases as
the local kernel has, we can end up with a WRLCK style kernel lease for the
second opener where locking.tdb only indicates a level2 oplock. Getting a
kernel oplock break signal with just a level2 oplock in locking.tdb is
something smbd is not prepared for. For example after sending out the break in
response to the kernel signal we set a timeout, waiting for a reply.

More work needs to be done to make level2 kernel oplocks real for us. This
patch addresses a real problem we have right now without them.
source3/smbd/oplock.c