AI Trajectory

null

{
  "EnableConfigs": [
    "RDS",
    "RDS_TCP"
  ],
  "FocusSymbols": [
    "rds_send_xmit",
    "rds_tcp_reset_callbacks",
    "rds_conn_shutdown"
  ],
  "KMSANReasoning": "KMSAN is specifically designed to detect uses of uninitialized memory and information leaks to user space. This patch focuses entirely on fixing concurrency and synchronization issues within the RDS subsystem. It replaces non-atomic bit clears with atomic operations, uses bit locks (`test_and_set_bit_lock`) to properly quiesce transmit and receive paths, and adds memory barriers (`wq_has_sleeper`) to prevent race conditions and lost wake-ups. The patch does not introduce new data structures, modify memory allocations, or alter data copied to user space or sent over the network. Therefore, there is no risk of uninitialized memory usage or info-leaks exposed by these changes. Any potential bugs introduced by this patch would be concurrency issues, race conditions, or deadlocks, which are best caught by standard bug detectors like KASAN, KCSAN, and LOCKDEP.",
  "NeedsKMSAN": false,
  "Reasoning": "The patch fixes a race condition during RDS connection shutdown and reset, where the RDS_IN_XMIT and RDS_RECV_REFILL flags could be clobbered or re-acquired concurrently. It uses test_and_set_bit_lock to properly quiesce the transmit and receive paths, and wq_has_sleeper to ensure a full memory barrier when checking the wait queue. This is a functional change in the core RDS networking logic that is reachable and worth fuzzing.",
  "WorthFuzzing": true
}

null

{
  "PatchDiff": "commit be82afb69cde1b5e443f03e7ff227b96fbf53f15\nAuthor: syz-cluster \u003ctriage@syzkaller.com\u003e\nDate:   Sun Aug 16 00:26:31 2026 +0000\n\n    syz-cluster: applied patch under review\n\ndiff --git a/net/rds/connection.c b/net/rds/connection.c\nindex 7c8ab8e973e1b..a10b667c06c87 100644\n--- a/net/rds/connection.c\n+++ b/net/rds/connection.c\n@@ -120,7 +120,15 @@ static void rds_conn_path_reset(struct rds_conn_path *cp)\n \n \trds_stats_inc(s_conn_reset);\n \trds_send_path_reset(cp);\n-\tcp-\u003ecp_flags = 0;\n+\n+\t/* Clear the bits the reset is responsible for individually: a\n+\t * blanket cp_flags = 0 is a plain store that can clobber a\n+\t * concurrent atomic read-modify-write on the same word.\n+\t * RDS_IN_XMIT and RDS_RECV_REFILL are owned by the caller,\n+\t * which releases them once the teardown is complete.\n+\t */\n+\tclear_bit(RDS_LL_SEND_FULL, \u0026cp-\u003ecp_flags);\n+\tclear_bit(RDS_RECONNECT_PENDING, \u0026cp-\u003ecp_flags);\n \n \t/* Do not clear next_rx_seq here, else we cannot distinguish\n \t * retransmitted packets from new packets, and will hand all\n@@ -406,14 +414,32 @@ void rds_conn_shutdown(struct rds_conn_path *cp)\n \t\t}\n \t\tmutex_unlock(\u0026cp-\u003ecp_cm_lock);\n \n+\t\t/* Quiesce the transmit and receive-refill paths by\n+\t\t * acquiring their bit locks, not merely waiting for\n+\t\t * them to be released: with a plain wait, either path\n+\t\t * can re-take its lock the instant after we sample it\n+\t\t * clear and then run concurrently with the transport\n+\t\t * shutdown and the path reset below.  Holding both\n+\t\t * locks across the teardown makes that structurally\n+\t\t * impossible.\n+\t\t */\n \t\twait_event(cp-\u003ecp_waitq,\n-\t\t\t   !test_bit(RDS_IN_XMIT, \u0026cp-\u003ecp_flags));\n+\t\t\t   !test_and_set_bit_lock(RDS_IN_XMIT, \u0026cp-\u003ecp_flags));\n \t\twait_event(cp-\u003ecp_waitq,\n-\t\t\t   !test_bit(RDS_RECV_REFILL, \u0026cp-\u003ecp_flags));\n+\t\t\t   !test_and_set_bit(RDS_RECV_REFILL, \u0026cp-\u003ecp_flags));\n \n \t\tconn-\u003ec_trans-\u003econn_path_shutdown(cp);\n \t\trds_conn_path_reset(cp);\n \n+\t\t/* Release the two locks and wake any waiter (e.g.\n+\t\t * rds_tcp_reset_callbacks()) that blocked on them while\n+\t\t * we held them.  rds_conn_path_reset() leaves both bits\n+\t\t * alone: ownership ends here, not inside the reset.\n+\t\t */\n+\t\tclear_bit_unlock(RDS_IN_XMIT, \u0026cp-\u003ecp_flags);\n+\t\tclear_bit(RDS_RECV_REFILL, \u0026cp-\u003ecp_flags);\n+\t\twake_up_all(\u0026cp-\u003ecp_waitq);\n+\n \t\tif (!rds_conn_path_transition(cp, RDS_CONN_DISCONNECTING,\n \t\t\t\t\t      RDS_CONN_DOWN) \u0026\u0026\n \t\t    !rds_conn_path_transition(cp, RDS_CONN_ERROR,\ndiff --git a/net/rds/send.c b/net/rds/send.c\nindex 15a1b97f13e76..b90e0586f818c 100644\n--- a/net/rds/send.c\n+++ b/net/rds/send.c\n@@ -114,8 +114,13 @@ static void release_in_xmit(struct rds_conn_path *cp)\n \t * hot path and finding waiters is very rare.  We don't want to walk\n \t * the system-wide hashed waitqueue buckets in the fast path only to\n \t * almost never find waiters.\n+\t *\n+\t * wq_has_sleeper() supplies the full barrier that orders the wait\n+\t * queue read after the bit clear; clear_bit_unlock() alone is only\n+\t * a release and would let this check read a stale empty queue,\n+\t * losing the wake-up.\n \t */\n-\tif (waitqueue_active(\u0026cp-\u003ecp_waitq))\n+\tif (wq_has_sleeper(\u0026cp-\u003ecp_waitq))\n \t\twake_up_all(\u0026cp-\u003ecp_waitq);\n }\n \n@@ -239,8 +244,9 @@ int rds_send_xmit(struct rds_conn_path *cp)\n \tWRITE_ONCE(cp-\u003ecp_send_gen, send_gen);\n \n \t/*\n-\t * rds_conn_shutdown() sets the conn state and then tests RDS_IN_XMIT,\n-\t * we do the opposite to avoid races.\n+\t * rds_conn_shutdown() sets the conn state and then acquires\n+\t * RDS_IN_XMIT; we take the lock first and then check the state,\n+\t * so one of us is guaranteed to see the other's update.\n \t */\n \tif (!rds_conn_path_up(cp)) {\n \t\trelease_in_xmit(cp);\ndiff --git a/net/rds/tcp.c b/net/rds/tcp.c\nindex b263634ac750d..1ff9e846dfc7c 100644\n--- a/net/rds/tcp.c\n+++ b/net/rds/tcp.c\n@@ -115,45 +115,66 @@ void rds_tcp_restore_callbacks(struct socket *sock,\n }\n \n /*\n- * rds_tcp_reset_callbacks() switches the to the new sock and\n- * returns the existing tc-\u003et_sock.\n+ * rds_tcp_reset_callbacks() switches a path to a new socket and\n+ * releases the old one it finds in tc-\u003et_sock, resolving a duelling\n+ * SYN.\n  *\n- * The only functions that set tc-\u003et_sock are rds_tcp_set_callbacks\n- * and rds_tcp_reset_callbacks.  Send and receive trust that\n- * it is set.  The absence of RDS_CONN_UP bit protects those paths\n- * from being called while it isn't set.\n+ * tc-\u003et_sock is set by rds_tcp_set_callbacks() and cleared by\n+ * rds_tcp_restore_callbacks(), from rds_tcp_conn_path_shutdown() and\n+ * from here.  Send and receive trust that it is set: the absence of\n+ * RDS_CONN_UP protects those paths from being called while it isn't,\n+ * and the swap done here runs under RDS_IN_XMIT so that it cannot\n+ * interleave with a sender already inside rds_send_xmit().\n  */\n void rds_tcp_reset_callbacks(struct socket *sock,\n \t\t\t     struct rds_conn_path *cp)\n {\n \tstruct rds_tcp_connection *tc = cp-\u003ecp_transport_data;\n-\tstruct socket *osock = tc-\u003et_sock;\n-\n-\tif (!osock)\n-\t\tgoto newsock;\n+\tstruct socket *osock;\n \n \t/* Need to resolve a duelling SYN between peers.\n \t * We have an outstanding SYN to this peer, which may\n \t * potentially have transitioned to the RDS_CONN_UP state,\n \t * so we must quiesce any send threads before resetting\n-\t * cp_transport_data. We quiesce these threads by setting\n-\t * cp_state to something other than RDS_CONN_UP, and then\n-\t * waiting for any existing threads in rds_send_xmit to\n-\t * complete release_in_xmit(). (Subsequent threads entering\n-\t * rds_send_xmit() will bail on !rds_conn_up().\n+\t * cp_transport_data.  Setting cp_state to something other\n+\t * than RDS_CONN_UP stops new senders, and owning RDS_IN_XMIT\n+\t * excludes any thread already inside rds_send_xmit() for the\n+\t * whole socket swap and the rds_send_path_reset() below.\n \t *\n-\t * However an incoming syn-ack at this point would end up\n-\t * marking the conn as RDS_CONN_UP, and would again permit\n-\t * rds_send_xmi() threads through, so ideally we would\n-\t * synchronize on RDS_CONN_UP after lock_sock(), but cannot\n-\t * do that: waiting on !RDS_IN_XMIT after lock_sock() may\n-\t * end up deadlocking with tcp_sendmsg(), and the RDS_IN_XMIT\n-\t * would not get set. As a result, we set c_state to\n-\t * RDS_CONN_RESETTTING, to ensure that rds_tcp_state_change\n-\t * cannot mark rds_conn_path_up() in the window before lock_sock()\n+\t * An incoming syn-ack at this point would end up marking the\n+\t * conn as RDS_CONN_UP, and would again permit rds_send_xmit()\n+\t * threads through, so ideally we would synchronize on\n+\t * RDS_CONN_UP after lock_sock(), but cannot do that: acquiring\n+\t * RDS_IN_XMIT after lock_sock() may end up deadlocking with\n+\t * tcp_sendmsg(), which takes the socket lock while holding\n+\t * RDS_IN_XMIT.  As a result, we set c_state to\n+\t * RDS_CONN_RESETTING, to ensure that rds_tcp_state_change\n+\t * cannot mark rds_conn_path_up() in the window before\n+\t * lock_sock().\n+\t *\n+\t * Only make that transition if the path is still connecting\n+\t * (or already resetting from an earlier duel), so that a\n+\t * concurrent shutdown's RDS_CONN_ERROR/RDS_CONN_DISCONNECTING\n+\t * is not overwritten; a path in any other state is dropped\n+\t * and its pending shutdown wins.\n+\t */\n+\tif (!rds_conn_path_transition(cp, RDS_CONN_CONNECTING,\n+\t\t\t\t      RDS_CONN_RESETTING) \u0026\u0026\n+\t    !rds_conn_path_transition(cp, RDS_CONN_RESETTING,\n+\t\t\t\t      RDS_CONN_RESETTING))\n+\t\trds_conn_path_drop(cp, 0);\n+\twait_event(cp-\u003ecp_waitq,\n+\t\t   !test_and_set_bit_lock(RDS_IN_XMIT, \u0026cp-\u003ecp_flags));\n+\n+\t/* Read t_sock only while owning RDS_IN_XMIT.  The teardown in\n+\t * rds_conn_shutdown() releases the old socket and clears\n+\t * t_sock, so a pointer sampled before the wait can be stale\n+\t * by the time we wake up.\n \t */\n-\tatomic_set(\u0026cp-\u003ecp_state, RDS_CONN_RESETTING);\n-\twait_event(cp-\u003ecp_waitq, !test_bit(RDS_IN_XMIT, \u0026cp-\u003ecp_flags));\n+\tosock = tc-\u003et_sock;\n+\tif (!osock)\n+\t\tgoto newsock;\n+\n \t/* reset receive side state for rds_tcp_data_recv() for osock  */\n \tcancel_delayed_work_sync(\u0026cp-\u003ecp_send_w);\n \tcancel_delayed_work_sync(\u0026cp-\u003ecp_recv_w);\n@@ -172,6 +193,9 @@ void rds_tcp_reset_callbacks(struct socket *sock,\n \tlock_sock(sock-\u003esk);\n \trds_tcp_set_callbacks(sock, cp);\n \trelease_sock(sock-\u003esk);\n+\n+\tclear_bit_unlock(RDS_IN_XMIT, \u0026cp-\u003ecp_flags);\n+\twake_up_all(\u0026cp-\u003ecp_waitq);\n }\n \n /* Add tc to rds_tcp_tc_list and set tc-\u003et_sock. See comments\n"
}

best-expensive

null

{
  "EnableConfigs": [
    "RDS",
    "RDS_TCP"
  ],
  "FocusSymbols": [
    "rds_send_xmit",
    "rds_tcp_reset_callbacks",
    "rds_conn_shutdown"
  ],
  "Reasoning": "The patch fixes a race condition during RDS connection shutdown and reset, where the RDS_IN_XMIT and RDS_RECV_REFILL flags could be clobbered or re-acquired concurrently. It uses test_and_set_bit_lock to properly quiesce the transmit and receive paths, and wq_has_sleeper to ensure a full memory barrier when checking the wait queue. This is a functional change in the core RDS networking logic that is reachable and worth fuzzing.",
  "WorthFuzzing": true
}

You are an expert Linux kernel maintainer.
Your job is to review a provided patch series and determine
if it makes functional changes to the kernel that should be fuzzed.

IMPORTANT: The changes have ALREADY been applied and committed as the HEAD commit in
your workspace. Do NOT rely on your internal knowledge of the kernel. You must actively
use your code access tools to examine the actual source code and confirm any assumptions.

Return WorthFuzzing=false if the patch only contains:
- Modifications to Documentation/, Kconfig files, or code comments.
- Purely decorative changes, such as logging (e.g., pr_err, printk) or tracepoints.
- Changes to numeric constants or macros that do not functionally alter execution flow.
- Code paths that are impossible to reach in virtualized environments like GCE or QEMU,
  even when utilizing software-emulated hardware (e.g., usb gadget, mac80211_hwsim).
- Code in vendor-specific PCIe switch, SmartNIC, or GPU drivers (e.g., mlxsw, pds_core, qed,
  ionic, amdgpu) that require physical PCIe hardware cards not emulated in standard QEMU.
- Driver .remove, .shutdown, or pci_unregister_driver teardown callbacks (e.g., igb_remove)
  that are executed only during PCI hot-unplug or sysfs driver unbind operations.

If it modifies reachable core kernel logic, drivers, or architectures, use your code search
tools to verify the code can be executed, then return WorthFuzzing=true.

When returning WorthFuzzing=true, you MUST ALSO:
1. Extract any specific kernel functions that should be heavily fuzzed into FocusSymbols.
   Avoid listing generic hot-path functions to prevent skewed test distributions.
   Prefer non-static, non-inlined API entrypoint functions over internal static helper functions
   (which are inlined by the compiler and do not have distinct symbol addresses).
2. Identify any specific CONFIG_ options required to properly test this new/modified feature.
   Go and look into the Kconfig files and check for ifdefs around the code, do not make assumptions.
   Also check "depends on" lines in Kconfig to include any non-standard parent subsystem configs
   needed for Kbuild to compile the code statically into vmlinux. List them in the EnableConfigs
   output array, and DO NOT add a 'CONFIG_' prefix (e.g., return "NET_IPV4" instead of "CONFIG_NET_IPV4").
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit be82afb69cde1b5e443f03e7ff227b96fbf53f15
Author: syz-cluster <triage@syzkaller.com>
Date:   Sun Aug 16 00:26:31 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/rds/connection.c b/net/rds/connection.c
index 7c8ab8e973e1b..a10b667c06c87 100644
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -120,7 +120,15 @@ static void rds_conn_path_reset(struct rds_conn_path *cp)
 
 	rds_stats_inc(s_conn_reset);
 	rds_send_path_reset(cp);
-	cp->cp_flags = 0;
+
+	/* Clear the bits the reset is responsible for individually: a
+	 * blanket cp_flags = 0 is a plain store that can clobber a
+	 * concurrent atomic read-modify-write on the same word.
+	 * RDS_IN_XMIT and RDS_RECV_REFILL are owned by the caller,
+	 * which releases them once the teardown is complete.
+	 */
+	clear_bit(RDS_LL_SEND_FULL, &cp->cp_flags);
+	clear_bit(RDS_RECONNECT_PENDING, &cp->cp_flags);
 
 	/* Do not clear next_rx_seq here, else we cannot distinguish
 	 * retransmitted packets from new packets, and will hand all
@@ -406,14 +414,32 @@ void rds_conn_shutdown(struct rds_conn_path *cp)
 		}
 		mutex_unlock(&cp->cp_cm_lock);
 
+		/* Quiesce the transmit and receive-refill paths by
+		 * acquiring their bit locks, not merely waiting for
+		 * them to be released: with a plain wait, either path
+		 * can re-take its lock the instant after we sample it
+		 * clear and then run concurrently with the transport
+		 * shutdown and the path reset below.  Holding both
+		 * locks across the teardown makes that structurally
+		 * impossible.
+		 */
 		wait_event(cp->cp_waitq,
-			   !test_bit(RDS_IN_XMIT, &cp->cp_flags));
+			   !test_and_set_bit_lock(RDS_IN_XMIT, &cp->cp_flags));
 		wait_event(cp->cp_waitq,
-			   !test_bit(RDS_RECV_REFILL, &cp->cp_flags));
+			   !test_and_set_bit(RDS_RECV_REFILL, &cp->cp_flags));
 
 		conn->c_trans->conn_path_shutdown(cp);
 		rds_conn_path_reset(cp);
 
+		/* Release the two locks and wake any waiter (e.g.
+		 * rds_tcp_reset_callbacks()) that blocked on them while
+		 * we held them.  rds_conn_path_reset() leaves both bits
+		 * alone: ownership ends here, not inside the reset.
+		 */
+		clear_bit_unlock(RDS_IN_XMIT, &cp->cp_flags);
+		clear_bit(RDS_RECV_REFILL, &cp->cp_flags);
+		wake_up_all(&cp->cp_waitq);
+
 		if (!rds_conn_path_transition(cp, RDS_CONN_DISCONNECTING,
 					      RDS_CONN_DOWN) &&
 		    !rds_conn_path_transition(cp, RDS_CONN_ERROR,
diff --git a/net/rds/send.c b/net/rds/send.c
index 15a1b97f13e76..b90e0586f818c 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -114,8 +114,13 @@ static void release_in_xmit(struct rds_conn_path *cp)
 	 * hot path and finding waiters is very rare.  We don't want to walk
 	 * the system-wide hashed waitqueue buckets in the fast path only to
 	 * almost never find waiters.
+	 *
+	 * wq_has_sleeper() supplies the full barrier that orders the wait
+	 * queue read after the bit clear; clear_bit_unlock() alone is only
+	 * a release and would let this check read a stale empty queue,
+	 * losing the wake-up.
 	 */
-	if (waitqueue_active(&cp->cp_waitq))
+	if (wq_has_sleeper(&cp->cp_waitq))
 		wake_up_all(&cp->cp_waitq);
 }
 
@@ -239,8 +244,9 @@ int rds_send_xmit(struct rds_conn_path *cp)
 	WRITE_ONCE(cp->cp_send_gen, send_gen);
 
 	/*
-	 * rds_conn_shutdown() sets the conn state and then tests RDS_IN_XMIT,
-	 * we do the opposite to avoid races.
+	 * rds_conn_shutdown() sets the conn state and then acquires
+	 * RDS_IN_XMIT; we take the lock first and then check the state,
+	 * so one of us is guaranteed to see the other's update.
 	 */
 	if (!rds_conn_path_up(cp)) {
 		release_in_xmit(cp);
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index b263634ac750d..1ff9e846dfc7c 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -115,45 +115,66 @@ void rds_tcp_restore_callbacks(struct socket *sock,
 }
 
 /*
- * rds_tcp_reset_callbacks() switches the to the new sock and
- * returns the existing tc->t_sock.
+ * rds_tcp_reset_callbacks() switches a path to a new socket and
+ * releases the old one it finds in tc->t_sock, resolving a duelling
+ * SYN.
  *
- * The only functions that set tc->t_sock are rds_tcp_set_callbacks
- * and rds_tcp_reset_callbacks.  Send and receive trust that
- * it is set.  The absence of RDS_CONN_UP bit protects those paths
- * from being called while it isn't set.
+ * tc->t_sock is set by rds_tcp_set_callbacks() and cleared by
+ * rds_tcp_restore_callbacks(), from rds_tcp_conn_path_shutdown() and
+ * from here.  Send and receive trust that it is set: the absence of
+ * RDS_CONN_UP protects those paths from being called while it isn't,
+ * and the swap done here runs under RDS_IN_XMIT so that it cannot
+ * interleave with a sender already inside rds_send_xmit().
  */
 void rds_tcp_reset_callbacks(struct socket *sock,
 			     struct rds_conn_path *cp)
 {
 	struct rds_tcp_connection *tc = cp->cp_transport_data;
-	struct socket *osock = tc->t_sock;
-
-	if (!osock)
-		goto newsock;
+	struct socket *osock;
 
 	/* Need to resolve a duelling SYN between peers.
 	 * We have an outstanding SYN to this peer, which may
 	 * potentially have transitioned to the RDS_CONN_UP state,
 	 * so we must quiesce any send threads before resetting
-	 * cp_transport_data. We quiesce these threads by setting
-	 * cp_state to something other than RDS_CONN_UP, and then
-	 * waiting for any existing threads in rds_send_xmit to
-	 * complete release_in_xmit(). (Subsequent threads entering
-	 * rds_send_xmit() will bail on !rds_conn_up().
+	 * cp_transport_data.  Setting cp_state to something other
+	 * than RDS_CONN_UP stops new senders, and owning RDS_IN_XMIT
+	 * excludes any thread already inside rds_send_xmit() for the
+	 * whole socket swap and the rds_send_path_reset() below.
 	 *
-	 * However an incoming syn-ack at this point would end up
-	 * marking the conn as RDS_CONN_UP, and would again permit
-	 * rds_send_xmi() threads through, so ideally we would
-	 * synchronize on RDS_CONN_UP after lock_sock(), but cannot
-	 * do that: waiting on !RDS_IN_XMIT after lock_sock() may
-	 * end up deadlocking with tcp_sendmsg(), and the RDS_IN_XMIT
-	 * would not get set. As a result, we set c_state to
-	 * RDS_CONN_RESETTTING, to ensure that rds_tcp_state_change
-	 * cannot mark rds_conn_path_up() in the window before lock_sock()
+	 * An incoming syn-ack at this point would end up marking the
+	 * conn as RDS_CONN_UP, and would again permit rds_send_xmit()
+	 * threads through, so ideally we would synchronize on
+	 * RDS_CONN_UP after lock_sock(), but cannot do that: acquiring
+	 * RDS_IN_XMIT after lock_sock() may end up deadlocking with
+	 * tcp_sendmsg(), which takes the socket lock while holding
+	 * RDS_IN_XMIT.  As a result, we set c_state to
+	 * RDS_CONN_RESETTING, to ensure that rds_tcp_state_change
+	 * cannot mark rds_conn_path_up() in the window before
+	 * lock_sock().
+	 *
+	 * Only make that transition if the path is still connecting
+	 * (or already resetting from an earlier duel), so that a
+	 * concurrent shutdown's RDS_CONN_ERROR/RDS_CONN_DISCONNECTING
+	 * is not overwritten; a path in any other state is dropped
+	 * and its pending shutdown wins.
+	 */
+	if (!rds_conn_path_transition(cp, RDS_CONN_CONNECTING,
+				      RDS_CONN_RESETTING) &&
+	    !rds_conn_path_transition(cp, RDS_CONN_RESETTING,
+				      RDS_CONN_RESETTING))
+		rds_conn_path_drop(cp, 0);
+	wait_event(cp->cp_waitq,
+		   !test_and_set_bit_lock(RDS_IN_XMIT, &cp->cp_flags));
+
+	/* Read t_sock only while owning RDS_IN_XMIT.  The teardown in
+	 * rds_conn_shutdown() releases the old socket and clears
+	 * t_sock, so a pointer sampled before the wait can be stale
+	 * by the time we wake up.
 	 */
-	atomic_set(&cp->cp_state, RDS_CONN_RESETTING);
-	wait_event(cp->cp_waitq, !test_bit(RDS_IN_XMIT, &cp->cp_flags));
+	osock = tc->t_sock;
+	if (!osock)
+		goto newsock;
+
 	/* reset receive side state for rds_tcp_data_recv() for osock  */
 	cancel_delayed_work_sync(&cp->cp_send_w);
 	cancel_delayed_work_sync(&cp->cp_recv_w);
@@ -172,6 +193,9 @@ void rds_tcp_reset_callbacks(struct socket *sock,
 	lock_sock(sock->sk);
 	rds_tcp_set_callbacks(sock, cp);
 	release_sock(sock->sk);
+
+	clear_bit_unlock(RDS_IN_XMIT, &cp->cp_flags);
+	wake_up_all(&cp->cp_waitq);
 }
 
 /* Add tc to rds_tcp_tc_list and set tc->t_sock. See comments

gemini-3.1-pro-preview

null

null

							input: 4771
							output: 29
							thoughts: 412
						

**Analyzing a RDS Connection Handling Patch**

Okay, so I've got this patch that tweaks how Reliable Datagram Sockets (RDS) handles connections, specifically during shutdown and reset, across those three files: `connection.c`, `send.c`, and `tcp.c`. It looks like it's addressing a race condition, which is always worth a closer look. They're using `test_and_set_bit_lock` instead of just waiting, and `wq_has_sleeper` for a stronger memory barrier. Smart move – that should really tighten things up around those `RDS_IN_XMIT` and `RDS_RECV_REFILL` flags. In `rds_tcp_reset_callbacks`, it seems they are making some lock management changes when resetting the socket.

This is a functional change deep in RDS, which could be important. Because RDS can operate over TCP in virtualized environments, this makes the patch interesting for analysis. I'm thinking, this definitely warrants some fuzzing. Gotta check the attack surface.

Let's see, what functions did they touch? Okay, I've got: `rds_conn_path_reset`, `rds_conn_shutdown`, `release_in_xmit`, `rds_send_xmit`, and `rds_tcp_reset_callbacks`. I need to figure out how exposed they are.

Right, `rds_conn_shutdown` is called from `rds_conn_destroy`, `rds_conn_drop`, etc., so that's interesting. `rds_send_xmit` is triggered by `rds_sendmsg`, which gives us a potential entry point and `rds_tcp_reset_callbacks` is called from `rds_tcp_accept_one`.

Okay, I'll go ahead and do a quick search for `rds_conn_shutdown`, `rds_send_xmit`, and `rds_tcp_reset_callbacks` to see how those are called, and get a better picture of the potential impact.

{
  "Expression": "rds_conn_shutdown",
  "PathPrefix": "net/rds/"
}

{
  "Output": "net/rds/connection.c=387=EXPORT_SYMBOL_GPL(rds_conn_create_outgoing);\nnet/rds/connection.c-388-\nnet/rds/connection.c:389:void rds_conn_shutdown(struct rds_conn_path *cp)\nnet/rds/connection.c-390-{\n--\nnet/rds/rds.h=815=struct rds_connection *rds_conn_create_outgoing(struct net *net,\n--\nnet/rds/rds.h-819-\t\t\t\t\t\tu8 tos, gfp_t gfp, int dev_if);\nnet/rds/rds.h:820:void rds_conn_shutdown(struct rds_conn_path *cpath);\nnet/rds/rds.h-821-void rds_conn_destroy(struct rds_connection *conn);\n--\nnet/rds/send.c=192=int rds_send_xmit(struct rds_conn_path *cp)\n--\nnet/rds/send.c-246-\t/*\nnet/rds/send.c:247:\t * rds_conn_shutdown() sets the conn state and then acquires\nnet/rds/send.c-248-\t * RDS_IN_XMIT; we take the lock first and then check the state,\n--\nnet/rds/tcp.c=129=void rds_tcp_reset_callbacks(struct socket *sock,\n--\nnet/rds/tcp.c-169-\t/* Read t_sock only while owning RDS_IN_XMIT.  The teardown in\nnet/rds/tcp.c:170:\t * rds_conn_shutdown() releases the old socket and clears\nnet/rds/tcp.c-171-\t * t_sock, so a pointer sampled before the wait can be stale\n--\nnet/rds/threads.c=243=void rds_shutdown_worker(struct work_struct *work)\n--\nnet/rds/threads.c-248-\nnet/rds/threads.c:249:\trds_conn_shutdown(cp);\nnet/rds/threads.c-250-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 6181
							output: 30
							thoughts: 40
						

Here's my take on the thought process, as if it were my own:

**Investigating the RDS Connection Shutdown Sequence**

Okay, so `rds_conn_shutdown` is the key function being called from `rds_shutdown_worker`. That immediately flags a potential area of concern when we're dealing with connection teardown. I need to understand the implications of this shutdown procedure.

My immediate thought is to trace the execution flow and identify where the network resources could be getting released. We need to be careful with resource management to avoid memory corruption, use after free errors, or deadlocks during a shutdown.

I'm thinking I should look closely at a couple of important pieces. First, I want to understand how the data is handled when a connection is shutting down, so I'll check `rds_send_xmit`. Secondly, I want to understand how the TCP connection is reset and how our callbacks are cleared during this procedure, so I'll review `rds_tcp_reset_callbacks`. Both of these are areas where we could easily introduce a subtle bug related to the shutdown sequence, and I know from experience that these types of issues can be difficult to debug.

{
  "Expression": "rds_send_xmit",
  "PathPrefix": "net/rds/"
}

{
  "Output": "net/rds/cong.c=217=void rds_cong_queue_updates(struct rds_cong_map *map)\n--\nnet/rds/cong.c-230-\t\t\trds_stats_inc(s_cong_update_queued);\nnet/rds/cong.c:231:\t\t\t/* We cannot inline the call to rds_send_xmit() here\nnet/rds/cong.c-232-\t\t\t * for two reasons (both pertaining to a TCP transport):\n--\nnet/rds/ib_cm.c=282=static void rds_ib_tasklet_fn_send(unsigned long data)\n--\nnet/rds/ib_cm.c-299-\t    test_bit(0, \u0026conn-\u003ec_map_queued)))\nnet/rds/ib_cm.c:300:\t\trds_send_xmit(\u0026ic-\u003econn-\u003ec_path[0]);\nnet/rds/ib_cm.c-301-}\n--\nnet/rds/ib_send.c=245=void rds_ib_send_cqe_handler(struct rds_ib_connection *ic, struct ib_wc *wc)\n--\nnet/rds/ib_send.c-335- *\nnet/rds/ib_send.c:336: * The RDS send code is essentially single-threaded; rds_send_xmit\nnet/rds/ib_send.c-337- * sets RDS_IN_XMIT to ensure exclusive access to the send ring.\n--\nnet/rds/loop.c=235=void rds_loop_net_exit(void)\n--\nnet/rds/loop.c-241- * This is missing .xmit_* because loop doesn't go through generic\nnet/rds/loop.c:242: * rds_send_xmit() and doesn't call rds_recv_incoming().  .listen_stop and\nnet/rds/loop.c-243- * .laddr_check are missing because transport.c doesn't iterate over\n--\nnet/rds/rds.h=540=struct rds_transport {\n--\nnet/rds/rds.h-580-\t/*\nnet/rds/rds.h:581:\t * .xmit is called by rds_send_xmit() to tell the transport to send\nnet/rds/rds.h-582-\t * part of a message.  The caller serializes on the send_sem so this\n--\nnet/rds/rds.h=957=void rds_send_path_reset(struct rds_conn_path *conn);\nnet/rds/rds.h:958:int rds_send_xmit(struct rds_conn_path *cp);\nnet/rds/rds.h-959-struct sockaddr_in;\n--\nnet/rds/send.c-44-\nnet/rds/send.c:45:/* When transmitting messages in rds_send_xmit, we need to emerge from\nnet/rds/send.c-46- * time to time and briefly release the CPU. Otherwise the softlock watchdog\n--\nnet/rds/send.c=59=static void rds_send_remove_from_sock(struct list_head *messages, int status);\n--\nnet/rds/send.c-62- * Reset the send state.  Callers must ensure that this doesn't race with\nnet/rds/send.c:63: * rds_send_xmit().\nnet/rds/send.c-64- */\n--\nnet/rds/send.c=133=static bool rds_mprds_cp0_catchup(struct rds_connection *conn)\n--\nnet/rds/send.c-191- */\nnet/rds/send.c:192:int rds_send_xmit(struct rds_conn_path *cp)\nnet/rds/send.c-193-{\n--\nnet/rds/send.c-555-}\nnet/rds/send.c:556:EXPORT_SYMBOL_GPL(rds_send_xmit);\nnet/rds/send.c-557-\n--\nnet/rds/send.c=690=static void rds_send_remove_from_sock(struct list_head *messages, int status)\n--\nnet/rds/send.c-765- * messages up to, and including, the given sequence number.  Messages are\nnet/rds/send.c:766: * moved to the retrans queue when rds_send_xmit picks them off the send\nnet/rds/send.c-767- * queue. This means that in the TCP case, the message may not have been\n--\nnet/rds/send.c=1152=int rds_sendmsg(struct socket *sock, struct msghdr *msg, size_t payload_len)\n--\nnet/rds/send.c-1449-\nnet/rds/send.c:1450:\tret = rds_send_xmit(cpath);\nnet/rds/send.c-1451-\tif (ret == -ENOMEM || ret == -EAGAIN) {\n--\nnet/rds/tcp.c=96=void rds_tcp_restore_callbacks(struct socket *sock,\n--\nnet/rds/tcp.c-126- * and the swap done here runs under RDS_IN_XMIT so that it cannot\nnet/rds/tcp.c:127: * interleave with a sender already inside rds_send_xmit().\nnet/rds/tcp.c-128- */\nnet/rds/tcp.c=129=void rds_tcp_reset_callbacks(struct socket *sock,\n--\nnet/rds/tcp.c-140-\t * than RDS_CONN_UP stops new senders, and owning RDS_IN_XMIT\nnet/rds/tcp.c:141:\t * excludes any thread already inside rds_send_xmit() for the\nnet/rds/tcp.c-142-\t * whole socket swap and the rds_send_path_reset() below.\n--\nnet/rds/tcp.c-144-\t * An incoming syn-ack at this point would end up marking the\nnet/rds/tcp.c:145:\t * conn as RDS_CONN_UP, and would again permit rds_send_xmit()\nnet/rds/tcp.c-146-\t * threads through, so ideally we would synchronize on\n--\nnet/rds/threads.c=191=void rds_send_worker(struct work_struct *work)\n--\nnet/rds/threads.c-199-\t\tclear_bit(RDS_LL_SEND_FULL, \u0026cp-\u003ecp_flags);\nnet/rds/threads.c:200:\t\tret = rds_send_xmit(cp);\nnet/rds/threads.c-201-\t\tcond_resched();\n"
}

gemini-3.1-pro-preview

null

null

							input: 8200
							output: 31
							thoughts: 57
						

Here's my summary, as though I'm thinking through this process:

**Internal Code Flow Considerations**

Okay, so I'm looking at how `rds_send_xmit` is used. It's definitely exported, meaning it's visible outside its immediate scope. Seems like `rds_sendmsg` and `rds_send_worker` are the key call sites. That gives me a handle on the data path for transmissions. Knowing these functions call `rds_send_xmit` tells me where to start looking when debugging a send issue.

Now, `rds_tcp_reset_callbacks`... that's the interesting one. The text suggests it is called from `rds_tcp_accept_one`. Need to verify this in the code. I'll need to check the call graph to be sure that `rds_tcp_accept_one` is the only caller of `rds_tcp_reset_callbacks`. If that's the case, it gives me a clear idea of when those callbacks are being reset. Understanding these dependencies are key to understanding the system.

{
  "Expression": "rds_tcp_reset_callbacks",
  "PathPrefix": "net/rds/"
}

{
  "Output": "net/rds/connection.c=389=void rds_conn_shutdown(struct rds_conn_path *cp)\n--\nnet/rds/connection.c-434-\t\t/* Release the two locks and wake any waiter (e.g.\nnet/rds/connection.c:435:\t\t * rds_tcp_reset_callbacks()) that blocked on them while\nnet/rds/connection.c-436-\t\t * we held them.  rds_conn_path_reset() leaves both bits\n--\nnet/rds/tcp.c=96=void rds_tcp_restore_callbacks(struct socket *sock,\n--\nnet/rds/tcp.c-117-/*\nnet/rds/tcp.c:118: * rds_tcp_reset_callbacks() switches a path to a new socket and\nnet/rds/tcp.c-119- * releases the old one it finds in tc-\u003et_sock, resolving a duelling\n--\nnet/rds/tcp.c-128- */\nnet/rds/tcp.c:129:void rds_tcp_reset_callbacks(struct socket *sock,\nnet/rds/tcp.c-130-\t\t\t     struct rds_conn_path *cp)\n--\nnet/rds/tcp.c-201-/* Add tc to rds_tcp_tc_list and set tc-\u003et_sock. See comments\nnet/rds/tcp.c:202: * above rds_tcp_reset_callbacks for notes about synchronization\nnet/rds/tcp.c-203- * with data path\n--\nnet/rds/tcp.h=74=void rds_tcp_set_callbacks(struct socket *sock, struct rds_conn_path *cp);\nnet/rds/tcp.h:75:void rds_tcp_reset_callbacks(struct socket *sock, struct rds_conn_path *cp);\nnet/rds/tcp.h-76-void rds_tcp_restore_callbacks(struct socket *sock,\n--\nnet/rds/tcp_listen.c=152=int rds_tcp_accept_one(struct rds_tcp_net *rtn)\n--\nnet/rds/tcp_listen.c-296-\t\t/* Duelling SYN has been handled in rds_tcp_accept_one() */\nnet/rds/tcp_listen.c:297:\t\trds_tcp_reset_callbacks(new_sock, cp);\nnet/rds/tcp_listen.c-298-\t\t/* rds_connect_path_complete() marks RDS_CONN_UP */\n"
}

gemini-3.1-pro-preview

null

null

							input: 9148
							output: 29
							thoughts: 37
						

Okay, here's my interpretation of those thoughts, summarized from my perspective as a networking expert:

**Investigating RDS TCP Reset Callbacks**

Alright, so the clue here is that `rds_tcp_reset_callbacks` is definitely called from within `rds_tcp_accept_one`. Good. That confirms a certain connection flow, or at least a specific point of integration. Now, I need to understand the larger context of *why* this happens. Knowing the call path is just the beginning. The next logical step, to get the bigger picture, is to investigate the callers of `rds_conn_shutdown`. That'll give me a view of what triggers the connection shutdown process, and therefore give me a better understanding of how the `reset_callbacks` are used in relation to the shutdown procedure. That should illuminate the failure and point me to potential root causes and fixes.

{
  "Expression": "rds_conn_shutdown",
  "PathPrefix": "net/rds/"
}

{
  "Output": "net/rds/connection.c=387=EXPORT_SYMBOL_GPL(rds_conn_create_outgoing);\nnet/rds/connection.c-388-\nnet/rds/connection.c:389:void rds_conn_shutdown(struct rds_conn_path *cp)\nnet/rds/connection.c-390-{\n--\nnet/rds/rds.h=815=struct rds_connection *rds_conn_create_outgoing(struct net *net,\n--\nnet/rds/rds.h-819-\t\t\t\t\t\tu8 tos, gfp_t gfp, int dev_if);\nnet/rds/rds.h:820:void rds_conn_shutdown(struct rds_conn_path *cpath);\nnet/rds/rds.h-821-void rds_conn_destroy(struct rds_connection *conn);\n--\nnet/rds/send.c=192=int rds_send_xmit(struct rds_conn_path *cp)\n--\nnet/rds/send.c-246-\t/*\nnet/rds/send.c:247:\t * rds_conn_shutdown() sets the conn state and then acquires\nnet/rds/send.c-248-\t * RDS_IN_XMIT; we take the lock first and then check the state,\n--\nnet/rds/tcp.c=129=void rds_tcp_reset_callbacks(struct socket *sock,\n--\nnet/rds/tcp.c-169-\t/* Read t_sock only while owning RDS_IN_XMIT.  The teardown in\nnet/rds/tcp.c:170:\t * rds_conn_shutdown() releases the old socket and clears\nnet/rds/tcp.c-171-\t * t_sock, so a pointer sampled before the wait can be stale\n--\nnet/rds/threads.c=243=void rds_shutdown_worker(struct work_struct *work)\n--\nnet/rds/threads.c-248-\nnet/rds/threads.c:249:\trds_conn_shutdown(cp);\nnet/rds/threads.c-250-}\n"
}

gemini-3.1-pro-preview

null

null

							input: 9938
							output: 29
							thoughts: 31
						

Here's my summary, as the expert:

**Investigating the Shutdown Sequence**

Okay, so I see `rds_conn_shutdown` being triggered within `rds_shutdown_worker`. Naturally, my next move is to understand the context. I need to trace back and identify the calling functions of `rds_shutdown_worker`. Understanding the call graph here is crucial to see what's *actually* driving the connection shutdown process. Knowing *who* is initiating this shutdown will provide the necessary context to troubleshoot any problems and ensure we're shutting down things in the proper sequence. Let's dig in and figure out the chain of events.

{
  "Expression": "rds_shutdown_worker",
  "PathPrefix": "net/rds/"
}

{
  "Output": "net/rds/connection.c=139=static void __rds_conn_path_init(struct rds_connection *conn,\n--\nnet/rds/connection.c-155-\tINIT_DELAYED_WORK(\u0026cp-\u003ecp_conn_w, rds_connect_worker);\nnet/rds/connection.c:156:\tINIT_WORK(\u0026cp-\u003ecp_down_w, rds_shutdown_worker);\nnet/rds/connection.c-157-\tmutex_init(\u0026cp-\u003ecp_cm_lock);\n--\nnet/rds/rds.h=1044=void rds_connect_worker(struct work_struct *);\nnet/rds/rds.h:1045:void rds_shutdown_worker(struct work_struct *);\nnet/rds/rds.h-1046-void rds_send_worker(struct work_struct *);\n--\nnet/rds/threads.c=218=void rds_recv_worker(struct work_struct *work)\n--\nnet/rds/threads.c-242-\nnet/rds/threads.c:243:void rds_shutdown_worker(struct work_struct *work)\nnet/rds/threads.c-244-{\n"
}

gemini-3.1-pro-preview

null

null

							input: 10443
							output: 26
							thoughts: 75
						

Here's my analysis of what needs attention when handling connection shutdown in RDS, approached from my expert perspective:

**Focusing on RDS Connection Shutdown**

Okay, so `rds_shutdown_worker` is the workqueue function that triggers when a connection is terminated. That's the entry point to investigate. Naturally, that's where the critical actions will be. Given that, I know the crucial functions to drill down into are:

*   `rds_send_xmit`: I need to understand how this handles ongoing transmissions during shutdown. Does it gracefully flush, cancel, or simply drop them? Are there race conditions to worry about?
*   `rds_tcp_reset_callbacks`: This is likely where the socket's associated callbacks are being cleared. I must check what these callbacks were and how it cleans up their internal state. I must ensure this is handled properly, considering potential concurrent access.
*   `rds_conn_shutdown`: The core shutdown logic has to be in this function. This is where I'll find how the connection state transitions and how resources are freed. It is likely it will call the other two as part of its functions.

Next, I'll examine the configuration aspects of the RDS subsystem. This way, I know all the variables in the mix. I have to know all the settings to understand how the shutdown process interacts with the rest of the system.

{
  "Expression": "config RDS",
  "PathPrefix": "net/rds/"
}

{
  "Output": "net/rds/Kconfig-2-\nnet/rds/Kconfig:3:config RDS\nnet/rds/Kconfig-4-\ttristate \"The Reliable Datagram Sockets Protocol\"\n--\nnet/rds/Kconfig-9-\nnet/rds/Kconfig:10:config RDS_RDMA\nnet/rds/Kconfig-11-\ttristate \"RDS over Infiniband\"\n--\nnet/rds/Kconfig-16-\nnet/rds/Kconfig:17:config RDS_TCP\nnet/rds/Kconfig-18-\ttristate \"RDS over TCP\"\n--\nnet/rds/Kconfig-24-\nnet/rds/Kconfig:25:config RDS_DEBUG\nnet/rds/Kconfig-26-\tbool \"RDS debugging messages\"\n"
}

gemini-3.1-pro-preview

null

null

							input: 11036
							output: 33
							thoughts: 28
						

Okay, here's my take on those thoughts, framed as an expert's internal monologue:

**Investigating RDS Configuration Dependencies**

Alright, so we're dealing with `RDS` and `RDS_TCP` configurations. My first instinct, as always, is to dive into the kernel configuration files. Specifically, I'm thinking about the dependency relationships. Where do these `RDS` options fit within the broader kernel configuration landscape? I need to understand what other features or modules they rely on. Let's start with `net/rds/Kconfig`. That's the obvious place to find the answers. From there, I can determine if any pre-requisites are enabled for `RDS` and `RDS_TCP`. It's all about ensuring that nothing is broken.

{
  "File": "net/rds/Kconfig",
  "FirstLine": 1,
  "LineCount": 100
}

{
  "Contents": "   1:\t# SPDX-License-Identifier: GPL-2.0-only\n   2:\t\n   3:\tconfig RDS\n   4:\t\ttristate \"The Reliable Datagram Sockets Protocol\"\n   5:\t\tdepends on INET\n   6:\t\thelp\n   7:\t\t  The RDS (Reliable Datagram Sockets) protocol provides reliable,\n   8:\t\t  sequenced delivery of datagrams over Infiniband or TCP.\n   9:\t\n  10:\tconfig RDS_RDMA\n  11:\t\ttristate \"RDS over Infiniband\"\n  12:\t\tdepends on RDS \u0026\u0026 INFINIBAND \u0026\u0026 INFINIBAND_ADDR_TRANS\n  13:\t\thelp\n  14:\t\t  Allow RDS to use Infiniband as a transport.\n  15:\t\t  This transport supports RDMA operations.\n  16:\t\n  17:\tconfig RDS_TCP\n  18:\t\ttristate \"RDS over TCP\"\n  19:\t\tdepends on RDS\n  20:\t\tdepends on IPV6 || !IPV6\n  21:\t\thelp\n  22:\t\t  Allow RDS to use TCP as a transport.\n  23:\t\t  This transport does not support RDMA operations.\n  24:\t\n  25:\tconfig RDS_DEBUG\n  26:\t\tbool \"RDS debugging messages\"\n  27:\t\tdepends on RDS\n  28:\t\tdefault n\n  29:\t\n  30:\tconfig GCOV_PROFILE_RDS\n  31:\t\tbool \"Enable GCOV profiling on RDS\"\n  32:\t\tdepends on GCOV_KERNEL\n  33:\t\thelp\n  34:\t\t  Enable GCOV profiling on RDS for checking which functions/lines\n  35:\t\t  are executed.\n  36:\t\n  37:\t\t  If unsure, say N.\n"
}

gemini-3.1-pro-preview

null

null

							input: 11711
							output: 31
							thoughts: 224
						

**My Thought Process on RDS Configuration and Relevant Functions**

Okay, so I'm looking at these RDS configurations, `RDS` and `RDS_TCP`, with `INET` usually enabled. I've got a few focus symbols to consider: `rds_send_xmit`, `rds_tcp_reset_callbacks`, and `rds_conn_shutdown`. I need to make sure I haven't missed any other potentially useful functions in this area.

`rds_conn_path_reset` looks promising, but it might be inlined or static, so that's a potential issue. `rds_conn_shutdown` is probably a stronger bet. And, I see `release_in_xmit` is static, which is not what I need. Ah, `rds_send_xmit` still seems like a good target.

Wait a second, `rds_tcp_reset_callbacks` – that's in `net/rds/tcp.c`. Let me quickly confirm if that function is exported or if it's static. Nope, it's not static, which is a good sign. Maybe `rds_tcp_accept_one` is an even better candidate? I see that `rds_tcp_accept_one` *calls* `rds_tcp_reset_callbacks`. Now I should check the callers of `rds_tcp_accept_one`.

{
  "Expression": "rds_tcp_accept_one",
  "PathPrefix": "net/rds/"
}

{
  "Output": "net/rds/rds.h=540=struct rds_transport {\n--\nnet/rds/rds.h-554-\t * conn_slots_available is invoked when a previously unavailable\nnet/rds/rds.h:555:\t * connection slot becomes available again. rds_tcp_accept_one_path may\nnet/rds/rds.h-556-\t * return -ENOBUFS if it cannot find an available slot, and then stashes\nnet/rds/rds.h-557-\t * the new socket in \"rds_tcp_accepted_sock\". This function re-issues\nnet/rds/rds.h:558:\t * `rds_tcp_accept_one_path`, which picks up the stashed socket and\nnet/rds/rds.h-559-\t * continuing where it left with \"-ENOBUFS\" last time.  This ensures\n--\nnet/rds/tcp.c=574=static void rds_tcp_accept_worker(struct work_struct *work)\n--\nnet/rds/tcp.c-579-\nnet/rds/tcp.c:580:\twhile (rds_tcp_accept_one(rtn) == 0)\nnet/rds/tcp.c-581-\t\tcond_resched();\n--\nnet/rds/tcp.h=8=struct rds_tcp_net {\nnet/rds/tcp.h:9:\t/* serialize \"rds_tcp_accept_one\" with \"rds_tcp_accept_lock\"\nnet/rds/tcp.h-10-\t * to protect \"rds_tcp_accepted_sock\"\n--\nnet/rds/tcp.h=27=struct rds_tcp_connection {\n--\nnet/rds/tcp.h-32-\t/* t_conn_path_lock synchronizes the connection establishment between\nnet/rds/tcp.h:33:\t * rds_tcp_accept_one and rds_tcp_conn_path_connect\nnet/rds/tcp.h-34-\t */\n--\nnet/rds/tcp.h=93=void rds_tcp_conn_slots_available(struct rds_connection *conn, bool fan_out);\nnet/rds/tcp.h:94:int rds_tcp_accept_one(struct rds_tcp_net *rtn);\nnet/rds/tcp.h-95-void rds_tcp_keepalive(struct socket *sock);\n--\nnet/rds/tcp_listen.c=60=rds_tcp_get_peer_sport(struct socket *sock)\n--\nnet/rds/tcp_listen.c-69-\nnet/rds/tcp_listen.c:70:/* rds_tcp_accept_one_path(): if accepting on cp_index \u003e 0, make sure the\nnet/rds/tcp_listen.c-71- * client's ipaddr \u003c server's ipaddr. Otherwise, close the accepted\n--\nnet/rds/tcp_listen.c=76=static struct rds_tcp_connection *\nnet/rds/tcp_listen.c:77:rds_tcp_accept_one_path(struct rds_connection *conn, struct socket *sock)\nnet/rds/tcp_listen.c-78-{\n--\nnet/rds/tcp_listen.c=108=void rds_tcp_conn_slots_available(struct rds_connection *conn, bool fan_out)\n--\nnet/rds/tcp_listen.c-138-\t/* As soon as a connection went down,\nnet/rds/tcp_listen.c:139:\t * it is safe to schedule a \"rds_tcp_accept_one\"\nnet/rds/tcp_listen.c-140-\t * attempt even if there are no connections pending:\nnet/rds/tcp_listen.c:141:\t * Function \"rds_tcp_accept_one\" won't block\nnet/rds/tcp_listen.c-142-\t * but simply return -EAGAIN in that case.\n--\nnet/rds/tcp_listen.c-146-\t * to be accepted prior to a free slot being available:\nnet/rds/tcp_listen.c:147:\t * the -ENOBUFS case in \"rds_tcp_accept_one\".\nnet/rds/tcp_listen.c-148-\t */\n--\nnet/rds/tcp_listen.c-151-\nnet/rds/tcp_listen.c:152:int rds_tcp_accept_one(struct rds_tcp_net *rtn)\nnet/rds/tcp_listen.c-153-{\n--\nnet/rds/tcp_listen.c-246-\t\t */\nnet/rds/tcp_listen.c:247:\t\trs_tcp = rds_tcp_accept_one_path(conn, new_sock);\nnet/rds/tcp_listen.c-248-\t\tif (!rs_tcp) {\n--\nnet/rds/tcp_listen.c-250-\t\t\t * \"rds_tcp_conn_slots_available\" triggers\nnet/rds/tcp_listen.c:251:\t\t\t * \"rds_tcp_accept_one\" again as soon as one of the\nnet/rds/tcp_listen.c-252-\t\t\t * connection slots becomes available again\n--\nnet/rds/tcp_listen.c-295-\tif (rs_tcp-\u003et_sock) {\nnet/rds/tcp_listen.c:296:\t\t/* Duelling SYN has been handled in rds_tcp_accept_one() */\nnet/rds/tcp_listen.c-297-\t\trds_tcp_reset_callbacks(new_sock, cp);\n"
}

gemini-3.1-pro-preview

null

null

							input: 13638
							output: 167
							thoughts: 181
						

**My Assessment of the RDS Connection Shutdown Patch**

Okay, so `rds_tcp_reset_callbacks` is looking good – no immediate red flags there. My understanding is that the configurations we're dealing with are centered around `RDS` and `RDS_TCP`. From what I'm seeing, the core elements here are really revolving around `rds_send_xmit`, `rds_tcp_reset_callbacks`, and `rds_conn_shutdown`.

The crux of this patch seems to address a pretty nasty race condition within the RDS connection shutdown and reset sequence. It sounds like there was a potential for the `RDS_IN_XMIT` and `RDS_RECV_REFILL` flags to get corrupted or, worse, re-acquired simultaneously, which is obviously a problem. The fix? Using `test_and_set_bit_lock` to ensure that the transmit and receive paths are properly "quiesced" – that's a smart approach. Also, the utilization of `wq_has_sleeper` to guarantee a full memory barrier when we're checking the wait queue is crucial for preventing those subtle memory-related issues.

This is a functional change, digging deep into the core RDS networking logic. It's definitely reachable and a prime candidate for fuzzing to shake out any remaining issues. I'll use `set-results` to track my work.

{
  "EnableConfigs": [
    "RDS",
    "RDS_TCP"
  ],
  "FocusSymbols": [
    "rds_send_xmit",
    "rds_tcp_reset_callbacks",
    "rds_conn_shutdown"
  ],
  "Reasoning": "The patch fixes a race condition during RDS connection shutdown and reset, where the RDS_IN_XMIT and RDS_RECV_REFILL flags could be clobbered or re-acquired concurrently. It uses test_and_set_bit_lock to properly quiesce the transmit and receive paths, and wq_has_sleeper to ensure a full memory barrier when checking the wait queue. This is a functional change in the core RDS networking logic that is reachable and worth fuzzing.",
  "WorthFuzzing": true
}

{
  "EnableConfigs": [
    "RDS",
    "RDS_TCP"
  ],
  "FocusSymbols": [
    "rds_send_xmit",
    "rds_tcp_reset_callbacks",
    "rds_conn_shutdown"
  ],
  "Reasoning": "The patch fixes a race condition during RDS connection shutdown and reset, where the RDS_IN_XMIT and RDS_RECV_REFILL flags could be clobbered or re-acquired concurrently. It uses test_and_set_bit_lock to properly quiesce the transmit and receive paths, and wq_has_sleeper to ensure a full memory barrier when checking the wait queue. This is a functional change in the core RDS networking logic that is reachable and worth fuzzing.",
  "WorthFuzzing": true
}

{
  "WorthFuzzing": true
}

null

best-expensive

null

{
  "KMSANReasoning": "KMSAN is specifically designed to detect uses of uninitialized memory and information leaks to user space. This patch focuses entirely on fixing concurrency and synchronization issues within the RDS subsystem. It replaces non-atomic bit clears with atomic operations, uses bit locks (`test_and_set_bit_lock`) to properly quiesce transmit and receive paths, and adds memory barriers (`wq_has_sleeper`) to prevent race conditions and lost wake-ups. The patch does not introduce new data structures, modify memory allocations, or alter data copied to user space or sent over the network. Therefore, there is no risk of uninitialized memory usage or info-leaks exposed by these changes. Any potential bugs introduced by this patch would be concurrency issues, race conditions, or deadlocks, which are best caught by standard bug detectors like KASAN, KCSAN, and LOCKDEP.",
  "NeedsKMSAN": false
}

You are an expert Linux kernel security engineer specializing in kernel memory
error detectors (KASAN and KMSAN). Your job is to review the provided patch series and
determine if the code changes justify spawning a dedicated KMSAN (KernelMemorySanitizer)
fuzzing session in addition to standard KASAN fuzzing.

CRITICAL DISTINCTION BETWEEN KASAN AND KMSAN:
- Standard KASAN kernel builds (upstream-apparmor-kasan.config) already enable
  a comprehensive suite of debugging tools and sanitizers, including KASAN
  (out-of-bounds accesses, use-after-free, double free, invalid free), LOCKDEP
  (locking bugs and deadlocks), UB-sanitizers, and memory corruption checks.
- KMSAN (KernelMemorySanitizer) detects reads of UNINITIALIZED memory (stack, heap,
  or page allocations) and kernel-to-user memory info-leaks.

Rule: THERE IS NO SENSE IN RUNNING A KMSAN SESSION IF A BUG CAN BE CAUGHT BY KASAN,
LOCKDEP, OR OTHER STANDARD BUG DETECTORS.
A dedicated KMSAN fuzzing session incurs significant resource costs. You must ONLY
set NeedsKMSAN=true if the code changes introduce or expose UNINITIALIZED MEMORY risks
that are detected ONLY by KMSAN.

Look holistically at the patch series and surrounding code. Even if no direct
uninitialized field accesses or new buffer allocations are added in the diff itself,
a patch may alter control flow, bounds checking, or data length calculations in ways
that change how the rest of the code operates on existing buffers (e.g. allowing
uninitialized stack/heap memory to be read, copied to user space, or used in control
flow). Do not hesitate to use your code access tools to inspect the surrounding code,
called functions, and callers.

Set NeedsKMSAN=true ONLY IF the patch introduces or modifies:
1. Kernel structures sent to user space (via copy_to_user, put_user, netlink skb
   attributes, ioctl output arguments, socket options, or BPF buffers) where fields
   or structure padding might not be fully initialized/zeroed.
2. Conditional logic or branching that depends on potentially uninitialized variables
   or struct fields.
3. Allocation or initialization of complex data structures where uninitialized fields
   could be read later in reachable code paths.
4. Bounds checks, lengths, or logic in a way that allows surrounding code to access
   uninitialized bytes of existing buffers.

Set NeedsKMSAN=false IF:
- The code changes primarily risk out-of-bounds access, array overflows, NULL pointer
  dereferences, locking deadlocks, or use-after-free bugs (these are already caught
  by KASAN, LOCKDEP, or standard bug detectors).
- All stack/heap structures touched or introduced by the patch are fully zeroed
  or initialized (e.g. using = {0}, memset, kzalloc) before being read or copied.
- The patch does not introduce any risk of uninitialized memory usage or info-leaks.

Use your code access tools to inspect the surrounding code if necessary, then provide
detailed KMSANReasoning contrasting KASAN vs KMSAN applicability for this patch.
Prefer calling several tools at the same time to save round-trips.


Use set-results tool to provide results of the analysis.
It must be called exactly once before the final reply.
Ignore results of this tool.

For your convenience, here is the diff of the changes:
commit be82afb69cde1b5e443f03e7ff227b96fbf53f15
Author: syz-cluster <triage@syzkaller.com>
Date:   Sun Aug 16 00:26:31 2026 +0000

    syz-cluster: applied patch under review

diff --git a/net/rds/connection.c b/net/rds/connection.c
index 7c8ab8e973e1b..a10b667c06c87 100644
--- a/net/rds/connection.c
+++ b/net/rds/connection.c
@@ -120,7 +120,15 @@ static void rds_conn_path_reset(struct rds_conn_path *cp)
 
 	rds_stats_inc(s_conn_reset);
 	rds_send_path_reset(cp);
-	cp->cp_flags = 0;
+
+	/* Clear the bits the reset is responsible for individually: a
+	 * blanket cp_flags = 0 is a plain store that can clobber a
+	 * concurrent atomic read-modify-write on the same word.
+	 * RDS_IN_XMIT and RDS_RECV_REFILL are owned by the caller,
+	 * which releases them once the teardown is complete.
+	 */
+	clear_bit(RDS_LL_SEND_FULL, &cp->cp_flags);
+	clear_bit(RDS_RECONNECT_PENDING, &cp->cp_flags);
 
 	/* Do not clear next_rx_seq here, else we cannot distinguish
 	 * retransmitted packets from new packets, and will hand all
@@ -406,14 +414,32 @@ void rds_conn_shutdown(struct rds_conn_path *cp)
 		}
 		mutex_unlock(&cp->cp_cm_lock);
 
+		/* Quiesce the transmit and receive-refill paths by
+		 * acquiring their bit locks, not merely waiting for
+		 * them to be released: with a plain wait, either path
+		 * can re-take its lock the instant after we sample it
+		 * clear and then run concurrently with the transport
+		 * shutdown and the path reset below.  Holding both
+		 * locks across the teardown makes that structurally
+		 * impossible.
+		 */
 		wait_event(cp->cp_waitq,
-			   !test_bit(RDS_IN_XMIT, &cp->cp_flags));
+			   !test_and_set_bit_lock(RDS_IN_XMIT, &cp->cp_flags));
 		wait_event(cp->cp_waitq,
-			   !test_bit(RDS_RECV_REFILL, &cp->cp_flags));
+			   !test_and_set_bit(RDS_RECV_REFILL, &cp->cp_flags));
 
 		conn->c_trans->conn_path_shutdown(cp);
 		rds_conn_path_reset(cp);
 
+		/* Release the two locks and wake any waiter (e.g.
+		 * rds_tcp_reset_callbacks()) that blocked on them while
+		 * we held them.  rds_conn_path_reset() leaves both bits
+		 * alone: ownership ends here, not inside the reset.
+		 */
+		clear_bit_unlock(RDS_IN_XMIT, &cp->cp_flags);
+		clear_bit(RDS_RECV_REFILL, &cp->cp_flags);
+		wake_up_all(&cp->cp_waitq);
+
 		if (!rds_conn_path_transition(cp, RDS_CONN_DISCONNECTING,
 					      RDS_CONN_DOWN) &&
 		    !rds_conn_path_transition(cp, RDS_CONN_ERROR,
diff --git a/net/rds/send.c b/net/rds/send.c
index 15a1b97f13e76..b90e0586f818c 100644
--- a/net/rds/send.c
+++ b/net/rds/send.c
@@ -114,8 +114,13 @@ static void release_in_xmit(struct rds_conn_path *cp)
 	 * hot path and finding waiters is very rare.  We don't want to walk
 	 * the system-wide hashed waitqueue buckets in the fast path only to
 	 * almost never find waiters.
+	 *
+	 * wq_has_sleeper() supplies the full barrier that orders the wait
+	 * queue read after the bit clear; clear_bit_unlock() alone is only
+	 * a release and would let this check read a stale empty queue,
+	 * losing the wake-up.
 	 */
-	if (waitqueue_active(&cp->cp_waitq))
+	if (wq_has_sleeper(&cp->cp_waitq))
 		wake_up_all(&cp->cp_waitq);
 }
 
@@ -239,8 +244,9 @@ int rds_send_xmit(struct rds_conn_path *cp)
 	WRITE_ONCE(cp->cp_send_gen, send_gen);
 
 	/*
-	 * rds_conn_shutdown() sets the conn state and then tests RDS_IN_XMIT,
-	 * we do the opposite to avoid races.
+	 * rds_conn_shutdown() sets the conn state and then acquires
+	 * RDS_IN_XMIT; we take the lock first and then check the state,
+	 * so one of us is guaranteed to see the other's update.
 	 */
 	if (!rds_conn_path_up(cp)) {
 		release_in_xmit(cp);
diff --git a/net/rds/tcp.c b/net/rds/tcp.c
index b263634ac750d..1ff9e846dfc7c 100644
--- a/net/rds/tcp.c
+++ b/net/rds/tcp.c
@@ -115,45 +115,66 @@ void rds_tcp_restore_callbacks(struct socket *sock,
 }
 
 /*
- * rds_tcp_reset_callbacks() switches the to the new sock and
- * returns the existing tc->t_sock.
+ * rds_tcp_reset_callbacks() switches a path to a new socket and
+ * releases the old one it finds in tc->t_sock, resolving a duelling
+ * SYN.
  *
- * The only functions that set tc->t_sock are rds_tcp_set_callbacks
- * and rds_tcp_reset_callbacks.  Send and receive trust that
- * it is set.  The absence of RDS_CONN_UP bit protects those paths
- * from being called while it isn't set.
+ * tc->t_sock is set by rds_tcp_set_callbacks() and cleared by
+ * rds_tcp_restore_callbacks(), from rds_tcp_conn_path_shutdown() and
+ * from here.  Send and receive trust that it is set: the absence of
+ * RDS_CONN_UP protects those paths from being called while it isn't,
+ * and the swap done here runs under RDS_IN_XMIT so that it cannot
+ * interleave with a sender already inside rds_send_xmit().
  */
 void rds_tcp_reset_callbacks(struct socket *sock,
 			     struct rds_conn_path *cp)
 {
 	struct rds_tcp_connection *tc = cp->cp_transport_data;
-	struct socket *osock = tc->t_sock;
-
-	if (!osock)
-		goto newsock;
+	struct socket *osock;
 
 	/* Need to resolve a duelling SYN between peers.
 	 * We have an outstanding SYN to this peer, which may
 	 * potentially have transitioned to the RDS_CONN_UP state,
 	 * so we must quiesce any send threads before resetting
-	 * cp_transport_data. We quiesce these threads by setting
-	 * cp_state to something other than RDS_CONN_UP, and then
-	 * waiting for any existing threads in rds_send_xmit to
-	 * complete release_in_xmit(). (Subsequent threads entering
-	 * rds_send_xmit() will bail on !rds_conn_up().
+	 * cp_transport_data.  Setting cp_state to something other
+	 * than RDS_CONN_UP stops new senders, and owning RDS_IN_XMIT
+	 * excludes any thread already inside rds_send_xmit() for the
+	 * whole socket swap and the rds_send_path_reset() below.
 	 *
-	 * However an incoming syn-ack at this point would end up
-	 * marking the conn as RDS_CONN_UP, and would again permit
-	 * rds_send_xmi() threads through, so ideally we would
-	 * synchronize on RDS_CONN_UP after lock_sock(), but cannot
-	 * do that: waiting on !RDS_IN_XMIT after lock_sock() may
-	 * end up deadlocking with tcp_sendmsg(), and the RDS_IN_XMIT
-	 * would not get set. As a result, we set c_state to
-	 * RDS_CONN_RESETTTING, to ensure that rds_tcp_state_change
-	 * cannot mark rds_conn_path_up() in the window before lock_sock()
+	 * An incoming syn-ack at this point would end up marking the
+	 * conn as RDS_CONN_UP, and would again permit rds_send_xmit()
+	 * threads through, so ideally we would synchronize on
+	 * RDS_CONN_UP after lock_sock(), but cannot do that: acquiring
+	 * RDS_IN_XMIT after lock_sock() may end up deadlocking with
+	 * tcp_sendmsg(), which takes the socket lock while holding
+	 * RDS_IN_XMIT.  As a result, we set c_state to
+	 * RDS_CONN_RESETTING, to ensure that rds_tcp_state_change
+	 * cannot mark rds_conn_path_up() in the window before
+	 * lock_sock().
+	 *
+	 * Only make that transition if the path is still connecting
+	 * (or already resetting from an earlier duel), so that a
+	 * concurrent shutdown's RDS_CONN_ERROR/RDS_CONN_DISCONNECTING
+	 * is not overwritten; a path in any other state is dropped
+	 * and its pending shutdown wins.
+	 */
+	if (!rds_conn_path_transition(cp, RDS_CONN_CONNECTING,
+				      RDS_CONN_RESETTING) &&
+	    !rds_conn_path_transition(cp, RDS_CONN_RESETTING,
+				      RDS_CONN_RESETTING))
+		rds_conn_path_drop(cp, 0);
+	wait_event(cp->cp_waitq,
+		   !test_and_set_bit_lock(RDS_IN_XMIT, &cp->cp_flags));
+
+	/* Read t_sock only while owning RDS_IN_XMIT.  The teardown in
+	 * rds_conn_shutdown() releases the old socket and clears
+	 * t_sock, so a pointer sampled before the wait can be stale
+	 * by the time we wake up.
 	 */
-	atomic_set(&cp->cp_state, RDS_CONN_RESETTING);
-	wait_event(cp->cp_waitq, !test_bit(RDS_IN_XMIT, &cp->cp_flags));
+	osock = tc->t_sock;
+	if (!osock)
+		goto newsock;
+
 	/* reset receive side state for rds_tcp_data_recv() for osock  */
 	cancel_delayed_work_sync(&cp->cp_send_w);
 	cancel_delayed_work_sync(&cp->cp_recv_w);
@@ -172,6 +193,9 @@ void rds_tcp_reset_callbacks(struct socket *sock,
 	lock_sock(sock->sk);
 	rds_tcp_set_callbacks(sock, cp);
 	release_sock(sock->sk);
+
+	clear_bit_unlock(RDS_IN_XMIT, &cp->cp_flags);
+	wake_up_all(&cp->cp_waitq);
 }
 
 /* Add tc to rds_tcp_tc_list and set tc->t_sock. See comments

gemini-3.1-pro-preview

null

null

							input: 4768
							output: 204
							thoughts: 623
						

**My Assessment of the RDS Patch**

Okay, so I've looked over this patch. It's touching `net/rds/connection.c`, `net/rds/send.c`, and `net/rds/tcp.c`, specifically focusing on how the `cp->cp_flags` bit flags (like `RDS_IN_XMIT`, `RDS_RECV_REFILL`, etc.) are managed. The key change is the replacement of basic bit manipulation with atomic operations using `test_and_set_bit_lock` and `clear_bit_unlock`, and the swap out of `waitqueue_active` with `wq_has_sleeper` to make sure memory barriers are working correctly. Also, it updates `rds_tcp_reset_callbacks` to properly handle socket swapping when `RDS_IN_XMIT` is active.

Basically, this is all about fixing concurrency problems in the Reliable Datagram Sockets (RDS) subsystem. Things like race conditions, potential deadlocks, and missed wake-ups are the targets here. I can see no changes that create new structures sent to user space, no new allocations, no changes to bounds checks or lengths that would expose uninitialized memory. Standard testing, KASAN, or LOCKDEP – especially if standard locks were involved (although, they are bit locks here), would pick up on these sorts of concurrency issues.

So, given that, I'm pretty confident that this patch doesn't introduce any risk of uninitialized memory usage.

Let's quickly recap the key changes again to confirm:

*   `rds_conn_path_reset` now clears specific bits instead of wiping `cp->cp_flags` to avoid clobbering concurrent atomic read-modify-write.
*   `rds_conn_shutdown` uses `test_and_set_bit_lock` and `test_and_set_bit` to quiesce transmit and receive-refill paths preventing concurrency
*   `release_in_xmit` now uses `wq_has_sleeper` instead of `waitqueue_active`, which provides a memory barrier
*   `rds_tcp_reset_callbacks` uses `test_and_set_bit_lock` to acquire `RDS_IN_XMIT` before reading `tc->t_sock` and swapping sockets.

All of these are strictly related to synchronization and concurrency – no uninitialized memory is in the picture here.

Therefore, my KMSANReasoning is pretty straightforward. KMSAN is there to catch uses of uninitialized memory. This patch focuses entirely on the synchronization and concurrency problems in the RDS subsystem, such as replacing non-atomic bit clears with atomic ones, correctly quiescing transmit/receive paths using bit locks, and adding memory barriers for wait queues. The patch does not introduce new data structures, modify memory allocations, or alter data being copied to user space. Hence, there is absolutely no possibility of uninitialized memory usage, and KASAN/LOCKDEP will catch any memory corruption or locking issues in this context. I will mark NeedsKMSAN as false.

{
  "KMSANReasoning": "KMSAN is specifically designed to detect uses of uninitialized memory and information leaks to user space. This patch focuses entirely on fixing concurrency and synchronization issues within the RDS subsystem. It replaces non-atomic bit clears with atomic operations, uses bit locks (`test_and_set_bit_lock`) to properly quiesce transmit and receive paths, and adds memory barriers (`wq_has_sleeper`) to prevent race conditions and lost wake-ups. The patch does not introduce new data structures, modify memory allocations, or alter data copied to user space or sent over the network. Therefore, there is no risk of uninitialized memory usage or info-leaks exposed by these changes. Any potential bugs introduced by this patch would be concurrency issues, race conditions, or deadlocks, which are best caught by standard bug detectors like KASAN, KCSAN, and LOCKDEP.",
  "NeedsKMSAN": false
}

{
  "KMSANReasoning": "KMSAN is specifically designed to detect uses of uninitialized memory and information leaks to user space. This patch focuses entirely on fixing concurrency and synchronization issues within the RDS subsystem. It replaces non-atomic bit clears with atomic operations, uses bit locks (`test_and_set_bit_lock`) to properly quiesce transmit and receive paths, and adds memory barriers (`wq_has_sleeper`) to prevent race conditions and lost wake-ups. The patch does not introduce new data structures, modify memory allocations, or alter data copied to user space or sent over the network. Therefore, there is no risk of uninitialized memory usage or info-leaks exposed by these changes. Any potential bugs introduced by this patch would be concurrency issues, race conditions, or deadlocks, which are best caught by standard bug detectors like KASAN, KCSAN, and LOCKDEP.",
  "NeedsKMSAN": false
}