From: Tom Talpey <tom@talpey.com>
To: David Howells <dhowells@redhat.com>
Cc: Steve French <sfrench@samba.org>,
Paulo Alcantara <pc@manguebit.com>,
Shyam Prasad N <nspmangalore@gmail.com>,
Rohith Surabattula <rohiths.msft@gmail.com>,
Jeff Layton <jlayton@kernel.org>,
linux-cifs@vger.kernel.org, netfs@lists.linux.dev,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH] cifs: Fix credit handling in cifs_io_subrequest cleanup
Date: Thu, 23 May 2024 11:00:40 -0400 [thread overview]
Message-ID: <28473e0b-bc3e-410a-a502-184595ae6f6c@talpey.com> (raw)
In-Reply-To: <581217.1716475935@warthog.procyon.org.uk>
On 5/23/2024 10:52 AM, David Howells wrote:
> Tom Talpey <tom@talpey.com> wrote:
>
>> From a protocol standpoint it's correct to reserve the credits while the
>> operation is in flight. But from a code standpoint it seems risky to
>> stop accounting for them. What if the operation is canceled, or times
>> out?
>
> No idea, TBH - SMB credits wrangling isn't my area of expertise. Note the
> patch is superfluous as smb2_readv/writev_callback() clear the credits at the
> end; worse, it's actually wrong as we're not allowed to touch [rw]data after
> calling ->async_readv()/->async_writev().
>
>> I'd quibble with the assertion that the server will "give us new credits
>> in the response". The number of granted credits is always the server's
>> decision, not guaranteed by the protocol (except for certain edge
>> conditions).
>
> It does give us new credits in the response, doesn't it? In
> hdr.CreditRequest - though I suppose this could be zero.
Yes, credits are consumed by requests and replenished in responses. One
credit is needed for any request or response, plus one credit per 64KB
chunk of payload (read, write, etc).
The value in hdr.CreditRequest is a hint when sent in a request, and
a small-ish integer, very possibly zero, in a response. Often, it
replenishes the credits consumed by the request it matches, but it can
be higher or lower at the server's choice. And it can be sent in any
response, before or after the one you might expect.
Tom.
>> I guess I'd suggest a deeper review by someone familiar with the
>> mechanics of fs/smb/client credit accounting. It might be ok!
>
> I've given Steve a patch to try and find where the double add occurs.
>
> David
>
>
prev parent reply other threads:[~2024-05-23 15:00 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-22 22:59 [RFC PATCH] cifs: Fix credit handling in cifs_io_subrequest cleanup David Howells
2024-05-23 14:41 ` Tom Talpey
2024-05-23 14:52 ` David Howells
2024-05-23 15:00 ` Tom Talpey [this message]
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=28473e0b-bc3e-410a-a502-184595ae6f6c@talpey.com \
--to=tom@talpey.com \
--cc=dhowells@redhat.com \
--cc=jlayton@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=netfs@lists.linux.dev \
--cc=nspmangalore@gmail.com \
--cc=pc@manguebit.com \
--cc=rohiths.msft@gmail.com \
--cc=sfrench@samba.org \
/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 read-only IMAP folder(s) and NNTP newsgroup(s).