From: Pavel Shilovsky <piastryyy@gmail.com>
To: ronnie sahlberg <ronniesahlberg@gmail.com>
Cc: Moritz M <mailinglist@moritzmueller.ee>,
linux-cifs <linux-cifs@vger.kernel.org>
Subject: Re: Possible timeout problem when opening a file twice on a SMB mount
Date: Tue, 24 Sep 2019 14:06:27 -0700 [thread overview]
Message-ID: <CAKywueQUuwRK7hbbJhdquVVPre2+8GBCvnrG76L-KodoMm9m6g@mail.gmail.com> (raw)
In-Reply-To: <CAKywueTOjoP-Jh7WWCi5XJhfzgK+KZs3kvHKuVG_HW0fnYYY7A@mail.gmail.com>
вт, 24 сент. 2019 г. в 12:05, Pavel Shilovsky <piastryyy@gmail.com>:
>
> 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
next prev parent reply other threads:[~2019-09-24 21:06 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-20 10:57 Possible timeout problem when opening a file twice on a SMB mount Moritz M
2019-09-20 23:26 ` Pavel Shilovsky
2019-09-23 14:04 ` Moritz M
2019-09-24 18:11 ` ronnie sahlberg
2019-09-24 19:05 ` Pavel Shilovsky
2019-09-24 21:06 ` Pavel Shilovsky [this message]
2019-09-25 19:23 ` Moritz M
2019-09-25 20:54 ` Pavel Shilovsky
2019-09-26 10:53 ` Moritz M
2019-09-26 18:58 ` Pavel Shilovsky
2019-10-30 13:26 ` Moritz M
2019-10-30 21:51 ` Pavel Shilovsky
2019-10-31 9:20 ` Moritz M
2019-10-31 21:01 ` Pavel Shilovsky
2019-09-24 19:33 ` Moritz M
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAKywueQUuwRK7hbbJhdquVVPre2+8GBCvnrG76L-KodoMm9m6g@mail.gmail.com \
--to=piastryyy@gmail.com \
--cc=linux-cifs@vger.kernel.org \
--cc=mailinglist@moritzmueller.ee \
--cc=ronniesahlberg@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).