[Samba] oplocks, kernel oplocks, kernel share modes, .. - how it all works?

[Jeremy Allison]

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.