Re: [PATCH bpf v2 2/3] tcp: Skip cond_resched() in inet_csk_listen_stop() under BPF context

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

New issues:
- [Medium] Unconditionally skipping `cond_resched()` in `inet_csk_listen_stop()` during BPF execution forces unbounded accept queue processing to run atomically, causing CPU soft lockups and RCU stalls.

Pre-existing issues:
- [High] This problem wasn't introduced by this patch, but the TCP BPF iterator acquires `lock_sock()` on unaccepted child sockets, causing destructive data races if the parent listener is closed concurrently.
--

commit ab882b1f2e506040f7bcef30415806e9b24c59a4
Author: Jiayuan Chen <jiayuan.chen@linux.dev>

tcp: Skip cond_resched() in inet_csk_listen_stop() under BPF context

This commit skips cond_resched() in inet_csk_listen_stop() when called under a
BPF context. This prevents a "sleeping function called from invalid context"
bug when an iterator BPF program calls bpf_sock_destroy() on a listener
socket.

> diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
> index 6257459bcee24..6a30f11384547 100644
> --- a/net/ipv4/inet_connection_sock.c
> +++ b/net/ipv4/inet_connection_sock.c

[Severity: High]
This isn't a bug introduced by this patch, but does the TCP BPF iterator
acquire lock_sock() on unaccepted child sockets, causing destructive data
races if the parent listener is closed concurrently?

If a TCP BPF iterator is running in bpf_iter_tcp_seq_show() and visits a
child socket in the ehash table that has not yet been accepted by userspace:

net/ipv4/tcp_ipv4.c:bpf_iter_tcp_seq_show() {
    ...
    if (sk_fullsock(sk))
        lock_sock(sk);
    ...
}

And concurrently, the parent listener is closed, invoking
inet_csk_listen_stop():

net/ipv4/inet_connection_sock.c:inet_csk_listen_stop() {
    ...
    bh_lock_sock(child);
    WARN_ON(sock_owned_by_user(child));
    ...
}

inet_csk_listen_stop() only takes the spinlock (bh_lock_sock()), triggers
the WARN_ON, and completely ignores the mutex, destructively modifying the
socket while the BPF program actively uses it.

> @@ -1520,7 +1520,8 @@ void inet_csk_listen_stop(struct sock *sk)
>  		local_bh_enable();
>  		sock_put(child);
>  
> -		cond_resched();
> +		if (!has_current_bpf_ctx())
> +			cond_resched();

[Severity: Medium]
Can unconditionally skipping cond_resched() here force unbounded accept queue
processing to run atomically?

Because the loop dismantles the accept queue (which can contain up to
somaxconn sockets), executing it entirely within a non-preemptible RCU
read-side section could cause CPU soft lockups and RCU stalls.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260906074135.185212-1-jiayuan.chen@linux.dev?part=2