Michael Tokarev
2023-Jan-24 17:29 UTC
[Samba] oplocks, kernel oplocks, kernel share modes, .. - how it all works?
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). /mjt
Ralph Boehme
2023-Jan-24 18:11 UTC
[Samba] oplocks, kernel oplocks, kernel share modes, .. - how it all works?
On 1/24/23 18:29, Michael Tokarev wrote:> I assumed LEASE() is okay because it is in fact SMB1 oplock, not a lease, > again as per your prior explanations.no, it's not. For an oplock smbstatus would print BATCH or EXCLUSIVE, cf source3/utils/status.c:print_share_mode(). -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/60332af4/OpenPGP_signature.sig>
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.