From: Tom Talpey <tom@talpey.com>
To: Pavel Shilovsky <piastryyy@gmail.com>,
Steve French <smfrench@gmail.com>,
Shyam Prasad N <nspmangalore@gmail.com>,
Ronnie Sahlberg <lsahlber@redhat.com>,
linux-cifs@vger.kernel.org
Subject: Re: [PATCH] CIFS: Wait for credits if at least one request is in flight
Date: Mon, 1 Feb 2021 22:39:37 -0500 [thread overview]
Message-ID: <40f473ff-bdd5-059c-36f1-d181eaa71200@talpey.com> (raw)
In-Reply-To: <20210202010105.236700-1-pshilov@microsoft.com>
It's reasonable to fail a request that can never have sufficient
credits to send, but EOPNOTSUPP is a really strange error to return.
The operation might work if the payload were smaller, right? So,
would a resource error such as EDEADLK be more meaningful, and allow
the caller to recover, even?
Also, can you elaborate on why this is only triggered when no
requests at all are in flight? Or is this some kind of corner
case for requests that need every credit the server currently
is offering?
Tom.
On 2/1/2021 8:01 PM, Pavel Shilovsky wrote:
> Currently we try to guess if a compound request is going to succeed
> waiting for credits or not based on the number of requests in flight.
> This approach doesn't work correctly all the time because there may
> be only one request in flight which is going to bring multiple credits
> satisfying the compound request.
>
> Change the behavior to fail a request only if there are no requests
> in flight at all and proceed waiting for credits otherwise.
>
> Cc: <stable@vger.kernel.org> # 5.1+
> Signed-off-by: Pavel Shilovsky <pshilov@microsoft.com>
> ---
> fs/cifs/transport.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/fs/cifs/transport.c b/fs/cifs/transport.c
> index 4ffbf8f965814..84f33fdd1f4e0 100644
> --- a/fs/cifs/transport.c
> +++ b/fs/cifs/transport.c
> @@ -659,10 +659,10 @@ wait_for_compound_request(struct TCP_Server_Info *server, int num,
> spin_lock(&server->req_lock);
> if (*credits < num) {
> /*
> - * Return immediately if not too many requests in flight since
> - * we will likely be stuck on waiting for credits.
> + * Return immediately if no requests in flight since
> + * we will be stuck on waiting for credits.
> */
> - if (server->in_flight < num - *credits) {
> + if (server->in_flight == 0) {
> spin_unlock(&server->req_lock);
> return -ENOTSUPP;
> }
>
next prev parent reply other threads:[~2021-02-02 3:49 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-02 1:01 [PATCH] CIFS: Wait for credits if at least one request is in flight Pavel Shilovsky
2021-02-02 3:39 ` Tom Talpey [this message]
2021-02-02 18:17 ` Pavel Shilovsky
2021-02-02 19:05 ` Tom Talpey
2021-02-02 19:45 ` Pavel Shilovsky
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=40f473ff-bdd5-059c-36f1-d181eaa71200@talpey.com \
--to=tom@talpey.com \
--cc=linux-cifs@vger.kernel.org \
--cc=lsahlber@redhat.com \
--cc=nspmangalore@gmail.com \
--cc=piastryyy@gmail.com \
--cc=smfrench@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