On 5/23/2024 10:52 AM, David Howells wrote:
Tom Talpey <tom@xxxxxxxxxx> 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
