[PATCH AUTOSEL 6.17-6.1] ksmbd: use sock_create_kern interface to create kernel socket

[PATCH AUTOSEL 6.17-6.1] ksmbd: use sock_create_kern interface to create kernel socket

[Sasha Levin]

From: Namjae Jeon <linkinjeon@kernel.org>

[ Upstream commit 3677ca67b9791481af16d86e47c3c7d1f2442f95 ]

we should use sock_create_kern() if the socket resides in kernel space.

Signed-off-by: Namjae Jeon <linkinjeon@kernel.org>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES – ksmbd now creates its listening sockets with `sock_create_kern()`,
so the socket is marked as a kernel socket and bypasses LSM policy
checks that would otherwise block the listener.
- `fs/smb/server/transport_tcp.c:474-505` replaces both IPv6 and IPv4
  calls to `sock_create()` with
  `sock_create_kern(current->nsproxy->net_ns, …)`, ensuring
  `__sock_create()` runs with `kern=1` (`net/socket.c:1661-1682`).
- When `kern` stays 0 (old code) LSMs such as SELinux and AppArmor
  enforce their policy hooks, which often deny kernel threads from
  opening INET stream sockets (`security/selinux/hooks.c:4797-4839`,
  `security/apparmor/lsm.c:1261-1301`). That failure bubbles back to
  `create_socket()` and leaves the ksmbd interface unconfigured
  (`fs/smb/server/transport_tcp.c:474-519`), so the server never starts
  listening.
- The change aligns ksmbd with other kernel networking users (e.g., the
  SMB client already calls `sock_create_kern()` in
  `fs/smb/client/connect.c:3366-3374`) and introduces no behavioral or
  API risk beyond correctly flagging the socket as kernel-owned.

Given that this fixes a real service outage on systems with enforcing
LSM policies, is tightly scoped, and carries minimal regression risk, it
is a strong candidate for stable backporting. Suggested verification:
bring up ksmbd under SELinux/AppArmor enforcing and confirm the listener
binds successfully.

 fs/smb/server/transport_tcp.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/fs/smb/server/transport_tcp.c b/fs/smb/server/transport_tcp.c
index 1009cb324fd51..43401d09c9db4 100644
--- a/fs/smb/server/transport_tcp.c
+++ b/fs/smb/server/transport_tcp.c
@@ -473,12 +473,13 @@ static int create_socket(struct interface *iface)
 	struct socket *ksmbd_socket;
 	bool ipv4 = false;
 
-	ret = sock_create(PF_INET6, SOCK_STREAM, IPPROTO_TCP, &ksmbd_socket);
+	ret = sock_create_kern(current->nsproxy->net_ns, PF_INET6, SOCK_STREAM,
+			IPPROTO_TCP, &ksmbd_socket);
 	if (ret) {
 		if (ret != -EAFNOSUPPORT)
 			pr_err("Can't create socket for ipv6, fallback to ipv4: %d\n", ret);
-		ret = sock_create(PF_INET, SOCK_STREAM, IPPROTO_TCP,
-				  &ksmbd_socket);
+		ret = sock_create_kern(current->nsproxy->net_ns, PF_INET,
+				SOCK_STREAM, IPPROTO_TCP, &ksmbd_socket);
 		if (ret) {
 			pr_err("Can't create socket for ipv4: %d\n", ret);
 			goto out_clear;
-- 
2.51.0

[PATCH AUTOSEL 6.17-6.1] smb: client: transport: avoid reconnects triggered by pending task work

[Sasha Levin]

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

[PATCH AUTOSEL 6.17] smb: client: update cfid->last_access_time in open_cached_dir_by_dentry()

[Sasha Levin]

From: Henrique Carvalho <henrique.carvalho@suse.com>

[ Upstream commit 5676398315b73f21d6a4e2d36606ce94e8afc79e ]

open_cached_dir_by_dentry() was missing an update of
cfid->last_access_time to jiffies, similar to what open_cached_dir()
has.

Add it to the function.

Signed-off-by: Henrique Carvalho <henrique.carvalho@suse.com>
Reviewed-by: Enzo Matsumiya <ematsumiya@suse.de>
Signed-off-by: Steve French <stfrench@microsoft.com>
Signed-off-by: Sasha Levin <sashal@kernel.org>
---

LLM Generated explanations, may be completely bogus:

YES
- The change makes `open_cached_dir_by_dentry()` refresh
  `cfid->last_access_time` just like `open_cached_dir()` already does,
  so cached handles looked up by dentry stay marked as recently used
  (`fs/smb/client/cached_dir.c:430`, compare with
  `fs/smb/client/cached_dir.c:197`). Without this, directories accessed
  through this path age out after the default 30 s timeout
  (`fs/smb/client/cifsfs.c:120`) regardless of activity.
- Eviction is driven by `cfids_laundromat_worker()`, which examines
  `last_access_time` to drop “stale” entries
  (`fs/smb/client/cached_dir.c:747-759`). Because lookups and
  revalidation frequently reach the cache via
  `open_cached_dir_by_dentry()` (`fs/smb/client/inode.c:2706` and
  `fs/smb/client/dir.c:732`), the missing update causes active
  directories to be torn down prematurely, forcing unnecessary reopen
  traffic and defeating the regression fix that introduced the field.
- The bug was introduced when `last_access_time` was added
  (`3edc68de5629`, included in v6.17), so affected stable trees already
  carry the infrastructure this patch relies on. The fix itself is a
  single assignment under the existing spinlock, so the regression risk
  is negligible and no additional prerequisites are required.

 fs/smb/client/cached_dir.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/smb/client/cached_dir.c b/fs/smb/client/cached_dir.c
index b69daeb1301b3..cc857a030a778 100644
--- a/fs/smb/client/cached_dir.c
+++ b/fs/smb/client/cached_dir.c
@@ -423,6 +423,7 @@ int open_cached_dir_by_dentry(struct cifs_tcon *tcon,
 			cifs_dbg(FYI, "found a cached file handle by dentry\n");
 			kref_get(&cfid->refcount);
 			*ret_cfid = cfid;
+			cfid->last_access_time = jiffies;
 			spin_unlock(&cfids->cfid_list_lock);
 			return 0;
 		}
-- 
2.51.0