[PATCH] af_unix: add cond_resched() when flushing receive queue on close

From: Wei Yang <redacted>

unix_release_sock() drains sk_receive_queue in a tight loop with no
rescheduling point.  Each iteration may do extra work depending on
the socket type: kfree_skb() runs unix_destruct_scm()->fput() for
SCM_RIGHTS fds on data sockets, and a LISTEN socket recurses into
unix_release_sock() for each embryonic child.

A long receive queue can hog the CPU and trip the softlockup watchdog
on CONFIG_PREEMPT_NONE kernels.  We have reproduced this multiple
times under stress-ng stress testing.  Add cond_resched() as done in
similar teardown loops (inet_csk_listen_stop, inet_twsk_purge,
close_files).

Signed-off-by: Wei Yang <redacted>
---
 net/unix/af_unix.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index f7a9d55eee8a..8b4624ce4178 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c

@@ -724,6 +724,7 @@ static void unix_release_sock(struct sock *sk, int embrion)
 
 		/* passed fds are erased in the kfree_skb hook */
 		kfree_skb_reason(skb, SKB_DROP_REASON_SOCKET_CLOSE);
+		cond_resched();
 	}
 
 	if (path.dentry)

-- 
2.43.5

On Sat, Jul 11, 2026 at 2:52 AM [off-list ref] wrote:

From: Wei Yang <redacted>

unix_release_sock() drains sk_receive_queue in a tight loop with no
rescheduling point.  Each iteration may do extra work depending on
the socket type: kfree_skb() runs unix_destruct_scm()->fput() for
SCM_RIGHTS fds on data sockets, and a LISTEN socket recurses into
unix_release_sock() for each embryonic child.

A long receive queue can hog the CPU and trip the softlockup watchdog
on CONFIG_PREEMPT_NONE kernels.

AFAIU, CONFIG_PREEMPT_NONE is no longer supported on
modern arch since 7dadeaa6e851, and it also mentions how bad
cond_resched() is.

I think you need to keep this patch downstream.