samba - Jan 2023 - oplocks, kernel oplocks, kernel share modes, .. - how it all works?

On Wed, Jan 25, 2023 at 12:00:09AM +0300, Michael Tokarev
wrote:
>24.01.2023 23:23, Jeremy Allison ?????:
>..
>>which means you end up with LEASE_OPLOCK, granted=SMB2_LEASE_NONE
>>which is what you see with smbstatus.
>>
>>If you turn on kernel oplocks = yes, I think you must also
>>set smb2 leases = no in order for this to work.
>
>I've set smb2 leases = no (to global). I don't see these LEASE()
anymore,
>I see "NONE", "BATCH" and "LEVEL_II" now, like
in old good times :)
Oh, very interesting. Something is wrong in our code then, as Ralph
already mentioned we have:

         capabilities = 0;
         if (lp_host_msdfs()) {
                 capabilities |= SMB2_CAP_DFS;
         }

         if (protocol >= PROTOCOL_SMB2_10 &&
             lp_smb2_leases() &&
             lp_oplocks(GLOBAL_SECTION_SNUM) &&
             !lp_kernel_oplocks(GLOBAL_SECTION_SNUM))
         {
                 capabilities |= SMB2_CAP_LEASING;
         }

so setting "kernel oplocks = yes" should prevent SMB2_CAP_LEASING
being returned to the client. A wireshark trace when you remove
the "smb2 leases = no" line would be good to look at.
>Here's an example now (with the above config and 'smb2
leases=no' added):
>
>78866  1006 DENY_WRITE 0x120089  RDONLY  BATCH /ws/ws   one   Tue Jan 24
23:48:23 2023
>78866  1006 DENY_NONE  0x120089  RDONLY  NONE  /ws/ws   two   Tue Jan 24
23:48:23 2023
>
>When I try to write to file "two", smbd does not care.  When
however I try
>to write to file "one", it seems to be reacting, getting SIGRT_3
signal,
>doing some exchanges with the client, and changing this BATCH oplock into
>NONE (so it works at least somehow). This ends up with F_SETLEASE, F_UNLCK
>call.  DENY_WRITE is still there for the file "one".
Yes, that's the code working correctly. When you do a local open, smbd
is getting the signal and telling the client to downgrade to oplock=NONE.

The "DENY_XXXX" modes have *nothing* to do with the oplock or lease
state,
they are restrictions on open types - not leasing or oplocks.
>I'm not sure it is what it should do here.  I'm trying to understand
what
>windows does with all this, if it will do the right thing when the file
>actually changes on the linux side..
Yes, it's doing the right thing.

On 1/24/23 22:12, Jeremy Allison wrote:
> On Wed, Jan 25, 2023 at 12:00:09AM +0300, Michael Tokarev wrote:
>> 24.01.2023 23:23, Jeremy Allison ?????:
>> ..
>>> which means you end up with LEASE_OPLOCK, granted=SMB2_LEASE_NONE
>>> which is what you see with smbstatus.
>>>
>>> If you turn on kernel oplocks = yes, I think you must also
>>> set smb2 leases = no in order for this to work.
>>
>> I've set smb2 leases = no (to global). I don't see these
LEASE() anymore,
>> I see "NONE", "BATCH" and "LEVEL_II" now,
like in old good times :)
> 
> Oh, very interesting. Something is wrong in our code then, as Ralph
> already mentioned we have:
> 
>  ??????? capabilities = 0;
>  ??????? if (lp_host_msdfs()) {
>  ??????????????? capabilities |= SMB2_CAP_DFS;
>  ??????? }
> 
>  ??????? if (protocol >= PROTOCOL_SMB2_10 &&
>  ??????????? lp_smb2_leases() &&
>  ??????????? lp_oplocks(GLOBAL_SECTION_SNUM) &&
>  ??????????? !lp_kernel_oplocks(GLOBAL_SECTION_SNUM))
>  ??????? {
>  ??????????????? capabilities |= SMB2_CAP_LEASING;
>  ??????? }
> 
> so setting "kernel oplocks = yes" should prevent SMB2_CAP_LEASING
> being returned to the client. A wireshark trace when you remove
> the "smb2 leases = no" line would be good to look at.
oh! That is the only place where we treat kernel oplocks as a global 
option. The docs and the rest of the code allow this as a per share 
option. Looks like we have a problem here.

@Michael: move the kernel oplocks setting to the global section, then 
things may start to work as expected.

-slow

-- 
Ralph Boehme, Samba Team                 https://samba.org/
SerNet Samba Team Lead      https://sernet.de/en/team-samba

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20230124/2a43abb5/OpenPGP_signature.sig>