Jeremy Allison
2023-Jan-24 20:23 UTC
[Samba] oplocks, kernel oplocks, kernel share modes, .. - how it all works?
On Tue, Jan 24, 2023 at 08:29:17PM +0300, Michael Tokarev via samba wrote:>24.01.2023 20:22, Ralph Boehme via samba wrote: >>What Samba version is this? This: >> >>>LEASE() >> >>... looks broken: the handle oplock/lease state claims to be a >>lease, which means the client didn't request an oplock but a lease >>which should not have happened in the first place, because the >>global leases capabiltiy is not signaled by the server when kernel >>oplocks are enabled. >> >>I assume this is 4.17? That saw substantial changes in the core open >>handling, I'm worried that some of the subtle oplock/lease handling >>was broken by those changes. > >Yes this is 4.17[.4], the current stable (debian build of it). > >I assumed LEASE() is okay because it is in fact SMB1 oplock, not a lease, >again as per your prior explanations. As I wrote before, this LEASE() >appeared here (instead of LEASE(RH) etc) when I enabled kernel oplocks >(for this share anyway).What are the settings in your smb.conf ? The 4.17 code does (in source3/smbd/open.c): 2727 if (oplock_request == LEASE_OPLOCK) { 2728 if (lease == NULL) { 2729 /* 2730 * The SMB2 layer should have checked this 2731 */ 2732 return NT_STATUS_INTERNAL_ERROR; 2733 } 2734 2735 granted = lease->lease_state; 2736 2737 if (lp_kernel_oplocks(SNUM(fsp->conn))) { 2738 DEBUG(10, ("No lease granted because kernel oplocks are enabled\n")); 2739 granted = SMB2_LEASE_NONE; 2740 } so you end up with oplock_request == LEASE_OPLOCK, granted=SMB2_LEASE_NONE. then further down is: 2781 if (oplock_request == LEASE_OPLOCK) { 2782 if (state.got_oplock) { 2783 granted &= ~SMB2_LEASE_HANDLE; 2784 } 2785 2786 fsp->oplock_type = LEASE_OPLOCK; 2787 2788 status = grant_fsp_lease(fsp, lck, lease, granted); 2789 if (!NT_STATUS_IS_OK(status)) { 2790 return status; 2791 2792 } 2793 2794 DBG_DEBUG("lease_state=%d\n", fsp->lease->lease.lease_state); 2795 } else { 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.
Ralph Boehme
2023-Jan-24 20:31 UTC
[Samba] oplocks, kernel oplocks, kernel share modes, .. - how it all works?
On 1/24/23 21:23, Jeremy Allison wrote:> If you turn on kernel oplocks = yes, I think you must also > set smb2 leases = no in order for this to work.see "git grep lp_kernel_oplocks". If kernel oplocks are enabled we don't set the leases cap in negport. Something smells fishy here... -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/95639d45/OpenPGP_signature.sig>
Michael Tokarev
2023-Jan-24 21:00 UTC
[Samba] oplocks, kernel oplocks, kernel share modes, .. - how it all works?
24.01.2023 23:23, Jeremy Allison ?????:> On Tue, Jan 24, 2023 at 08:29:17PM +0300, Michael Tokarev via samba wrote: >> 24.01.2023 20:22, Ralph Boehme via samba wrote: >>> What Samba version is this? This: >>> >>>> LEASE() >>> >>> ... looks broken: the handle oplock/lease state claims to be a lease, which means the client didn't request an oplock but a lease which should not >>> have happened in the first place, because the global leases capabiltiy is not signaled by the server when kernel oplocks are enabled. >>> >>> I assume this is 4.17? That saw substantial changes in the core open handling, I'm worried that some of the subtle oplock/lease handling was broken >>> by those changes. >> >> Yes this is 4.17[.4], the current stable (debian build of it). >> >> I assumed LEASE() is okay because it is in fact SMB1 oplock, not a lease, >> again as per your prior explanations.? As I wrote before, this LEASE() >> appeared here (instead of LEASE(RH) etc) when I enabled kernel oplocks >> (for this share anyway). > > What are the settings in your smb.conf ?Here it is (with other share definitions omitted): # Global parameters [global] netbios name = PANDA netbios aliases = FS log level = 1 prefork children = 2 realm = TLS.MSK.RU security = ADS server role = member server winbind use default domain = Yes workgroup = TLS idmap config * : range = 5000-5099 idmap config * : backend = tdb idmap config tls : unix_primary_group = yes idmap config tls : schema_mode = rfc2307 idmap config tls : range = 1000-4999 idmap config tls : backend = ad idmap_ldb:use rfc2307 = yes acl allow execute always = true [ws] comment = Workspace Area path = /ws/ws create mask = 0775 writable = yes kernel oplocks = yes ..> 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 :) 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". 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.. Thanks! /mjt