вт, 24 сент. 2019 г. в 12:05, Pavel Shilovsky <piastryyy@xxxxxxxxx>:
>
> Thanks Moritz for providing this information.
>
> It seems like a new long-term bug in the client code. The client
> requested a lease but the server responded with a batch Oplock value
> (0x9). Since the mount is SMB3.1.1 the client assumes that the server
> always responds with a lease thus interprets this as a Lease State -
> 0x9 matches in the bit mask only a READ lease flag (0x1). Later on
> when the client receives an oplock break from the server caused by the
> second OPEN, it looks at the caching level which is READ and skips the
> OPLOCK BREAK ACK step (according to the spec). That's why the app
> hangs waiting for the oplock break to be timed out.
>
> In order to fix it, we would need to tech the client to recognize
> Oplocks on SMB3+ mounts assuming that the server may return both
> Oplocks and Leases in response to CREATE command.
>
> Ronnie, what is the version of Samba are you using? It is up to the
> server to decide if Oplock or Lease is returned.
>
Moritz,
Could you try the following patch in your setup to see if it fixes the problem?
diff --git a/fs/cifs/smb2ops.c b/fs/cifs/smb2ops.c
index 047066493832..00d2ac80cd6e 100644
--- a/fs/cifs/smb2ops.c
+++ b/fs/cifs/smb2ops.c
@@ -3314,6 +3314,11 @@ smb21_set_oplock_level(struct cifsInodeInfo
*cinode, __u32 oplock,
if (oplock == SMB2_OPLOCK_LEVEL_NOCHANGE)
return;
+ /* Check if the server granted an oplock rather than a lease */
+ if (oplock & SMB2_OPLOCK_LEVEL_EXCLUSIVE)
+ return smb2_set_oplock_level(cinode, oplock, epoch,
+ purge_cache);
+
if (oplock & SMB2_LEASE_READ_CACHING_HE) {
new_oplock |= CIFS_CACHE_READ_FLG;
strcat(message, "R");
--
Best regards,
Pavel Shilovsky
