From: Sasha Levin <sashal@kernel.org>
To: patches@lists.linux.dev, stable@vger.kernel.org
Cc: Fiona Ebner <f.ebner@proxmox.com>,
Steve French <stfrench@microsoft.com>,
Sasha Levin <sashal@kernel.org>,
sfrench@samba.org, linux-cifs@vger.kernel.org,
samba-technical@lists.samba.org
Subject: [PATCH AUTOSEL 6.17-6.1] smb: client: transport: avoid reconnects triggered by pending task work
Date: Sat, 25 Oct 2025 12:00:33 -0400 [thread overview]
Message-ID: <20251025160905.3857885-402-sashal@kernel.org> (raw)
In-Reply-To: <20251025160905.3857885-1-sashal@kernel.org>
From: Fiona Ebner <f.ebner@proxmox.com>
[ Upstream commit 00be6f26a2a7c671f1402d74c4d3c30a5844660a ]
When io_uring is used in the same task as CIFS, there might be
unnecessary reconnects, causing issues in user-space applications
like QEMU with a log like:
> CIFS: VFS: \\10.10.100.81 Error -512 sending data on socket to server
Certain io_uring completions might be added to task_work with
notify_method being TWA_SIGNAL and thus TIF_NOTIFY_SIGNAL is set for
the task.
In __smb_send_rqst(), signals are masked before calling
smb_send_kvec(), but the masking does not apply to TIF_NOTIFY_SIGNAL.
If sk_stream_wait_memory() is reached via sock_sendmsg() while
TIF_NOTIFY_SIGNAL is set, signal_pending(current) will evaluate to
true there, and -EINTR will be propagated all the way from
sk_stream_wait_memory() to sock_sendmsg() in smb_send_kvec().
Afterwards, __smb_send_rqst() will see that not everything was written
and reconnect.
Signed-off-by: Fiona Ebner <f.ebner@proxmox.com>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---
LLM Generated explanations, may be completely bogus:
YES
- **Bug addressed:** When `sk_stream_wait_memory()` sees
`signal_pending(current)` it returns `-EINTR`
(net/core/stream.c:141-185). In CIFS, `__smb_send_rqst()` masks
regular signals but not `TIF_NOTIFY_SIGNAL`, so that `-EINTR` flows
back, hits the reconnect path (`rc = -ERESTARTSYS` plus
`cifs_signal_cifsd_for_reconnect()`) and forces unnecessary
disconnects with errors like `-512`
(fs/smb/client/transport.c:350-379).
- **Why it happens in practice:** io_uring queues task_work with
`notify_method = TWA_SIGNAL` (io_uring/io_uring.c:3844-3847), which
sets `TIF_NOTIFY_SIGNAL` and trips `signal_pending()` even though the
task only has task_work pending. CIFS previously treated this
indistinguishably from a real signal, so combining io_uring with SMB
writes caused spurious reconnects observed by users (commit message
symptom).
- **Fix mechanics:** The patch adds `<linux/task_work.h>`
(fs/smb/client/transport.c:25) and treats `-EINTR` as a transient
condition only when `task_work_pending(current)` reports queued task
work (fs/smb/client/transport.c:186-195). This keeps the existing
retry/backoff logic but prevents the reconnect machinery from running
on synthetic task-work signals. The comment at
fs/smb/client/transport.c:178-183 documents the scenario.
- **Safety:** Fatal or user-requested interrupts still break out because
`fatal_signal_pending(current)` is checked up front
(fs/smb/client/transport.c:268-272) and the new clause only fires when
both `rc == -EINTR` and task work is pending. If the condition
persists, the existing retry limit still returns `-EAGAIN`, so there
is no risk of livelock. `task_work_pending()` has been part of the API
since v5.18 (include/linux/task_work.h:24-27), so the helper is
available on active stable lines, and no other subsystems are touched.
- **Backport outlook:** The change is tiny, self-contained, and directly
fixes a user-visible regression without altering protocol semantics.
It should be safe to backport as-is; running the usual CIFS
regression/balance-of-tree network write tests would be the natural
follow-up.
fs/smb/client/transport.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/fs/smb/client/transport.c b/fs/smb/client/transport.c
index a61ba7f3fb86b..940e901071343 100644
--- a/fs/smb/client/transport.c
+++ b/fs/smb/client/transport.c
@@ -22,6 +22,7 @@
#include <linux/mempool.h>
#include <linux/sched/signal.h>
#include <linux/task_io_accounting_ops.h>
+#include <linux/task_work.h>
#include "cifspdu.h"
#include "cifsglob.h"
#include "cifsproto.h"
@@ -173,9 +174,16 @@ smb_send_kvec(struct TCP_Server_Info *server, struct msghdr *smb_msg,
* send a packet. In most cases if we fail to send
* after the retries we will kill the socket and
* reconnect which may clear the network problem.
+ *
+ * Even if regular signals are masked, EINTR might be
+ * propagated from sk_stream_wait_memory() to here when
+ * TIF_NOTIFY_SIGNAL is used for task work. For example,
+ * certain io_uring completions will use that. Treat
+ * having EINTR with pending task work the same as EAGAIN
+ * to avoid unnecessary reconnects.
*/
rc = sock_sendmsg(ssocket, smb_msg);
- if (rc == -EAGAIN) {
+ if (rc == -EAGAIN || unlikely(rc == -EINTR && task_work_pending(current))) {
retries++;
if (retries >= 14 ||
(!server->noblocksnd && (retries > 2))) {
--
2.51.0
next prev parent reply other threads:[~2025-10-25 16:27 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20251025160905.3857885-1-sashal@kernel.org>
2025-10-25 15:55 ` [PATCH AUTOSEL 6.17-6.1] ksmbd: use sock_create_kern interface to create kernel socket Sasha Levin
2025-10-25 16:00 ` Sasha Levin [this message]
2025-10-25 16:00 ` [PATCH AUTOSEL 6.17] smb: client: update cfid->last_access_time in open_cached_dir_by_dentry() Sasha Levin
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=20251025160905.3857885-402-sashal@kernel.org \
--to=sashal@kernel.org \
--cc=f.ebner@proxmox.com \
--cc=linux-cifs@vger.kernel.org \
--cc=patches@lists.linux.dev \
--cc=samba-technical@lists.samba.org \
--cc=sfrench@samba.org \
--cc=stable@vger.kernel.org \
--cc=stfrench@microsoft.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 read-only IMAP folder(s) and NNTP newsgroup(s).