From: David Howells <dhowells@redhat.com>
To: Steve French <sfrench@samba.org>, Shyam Prasad N <sprasad@microsoft.com>
Cc: dhowells@redhat.com, Paulo Alcantara <pc@manguebit.com>,
Ronnie Sahlberg <ronniesahlberg@gmail.com>,
Tom Talpey <tom@talpey.com>, Bharath SM <bharathsm@microsoft.com>,
jlayton@kernel.org, linux-cifs@vger.kernel.org
Subject: How to manage credits handling in cifs read and write paths?
Date: Thu, 21 Mar 2024 17:48:40 +0000 [thread overview]
Message-ID: <1419723.1711043320@warthog.procyon.org.uk> (raw)
Hi Steve, Shyam,
I'd like to make the attached change to add_credits_and_wake_if(). It's
called in various places along the error handling paths, but it's not obvious
that it's consistent and that we don't get double accounting.
The obvious change would be to clear credits->value if we return the credits
back to the pool. Assuming that's how this works. That makes it easier to
(a) clean up the netfs_io_subrequest struct or (b) renegotiate and retry with
it because I can just call it multiple times.
Also, add_credits_and_wake_if() wakes up server->request_q... but so do
cifs_add_credits() and smb2_add_credits(), so is this superfluous?
Additionally, what's the scope of a 'xid'? I think I should add one to each
subrequest I generate and deallocate it when the subrequest is freed. If
that's the case, can I add an explicit "rc" argument to free_xid()?
And finally, I have my cifs conversion to netfslib down to the same xfstest
failures as upstream[*]. Those patches can be found here, with an additional
one on top to address the credits and part of the xid thing:
https://git.kernel.org/pub/scm/linux/kernel/git/dhowells/linux-fs.git/log/?h=cifs-netfs
David
[*] With Samba; I still need to sort out ksmbd.
---
@@ -878,11 +878,12 @@ add_credits(struct TCP_Server_Info *server, const struct cifs_credits *credits,
static inline void
add_credits_and_wake_if(struct TCP_Server_Info *server,
- const struct cifs_credits *credits, const int optype)
+ struct cifs_credits *credits, const int optype)
{
if (credits->value) {
server->ops->add_credits(server, credits, optype);
wake_up(&server->request_q);
+ credits->value = 0;
}
}
reply other threads:[~2024-03-21 17:48 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1419723.1711043320@warthog.procyon.org.uk \
--to=dhowells@redhat.com \
--cc=bharathsm@microsoft.com \
--cc=jlayton@kernel.org \
--cc=linux-cifs@vger.kernel.org \
--cc=pc@manguebit.com \
--cc=ronniesahlberg@gmail.com \
--cc=sfrench@samba.org \
--cc=sprasad@microsoft.com \
--cc=tom@talpey.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