From: "Alexei Starovoitov" <alexei.starovoitov@gmail.com>
To: <sashiko-reviews@lists.linux.dev>, <bpf@vger.kernel.org>
Cc: <mptcp@lists.linux.dev>
Subject: Re: [PATCH bpf 06/15] bpf, sockmap: Give no progs to a TCP listener
Date: Mon, 02 Nov 2026 00:17:53 +0000 [thread overview]
Message-ID: <DMKAKRM51QKN.34OI7DN57OAV7@gmail.com> (raw)
In-Reply-To: <sashiko-outbox-192637@kernel.org>
On Sun, Nov 01, 2026 at 11:51 AM sashiko-bot@kernel.org <sashiko-bot@kernel.org> wrote:
>> + if (sk_is_tcp(sk) && sk->sk_state == TCP_LISTEN)
>> + goto no_progs;
>
> Because sock_map_del_link() checks the unlinked map's progs rather than
> whether that map actually installed programs on psock, won't removing the
> socket from Map B stop Map A's active verdict or parser callbacks (and
> potentially call sk_psock_stop_strp() on an uninitialized strparser if
> Map B had a stream_parser while Map A only had a verdict program)?
Not from this patch. sock_map_del_link() looks at the progs that the map
has at the time of the delete. Add a socket to map B, attach a prog to
map B, delete the socket. That stops the progs of map A today.
strp_stop() only sets a flag, and sk_psock_done_strp() checks
SK_PSOCK_RX_STRP_ENABLED.
> Wouldn't sock_map_link() then see TCP_CLOSE instead of TCP_LISTEN, skip
> the goto no_progs branch, and attach the map's programs and callbacks to a
> socket that can subsequently re-enter TCP_LISTEN?
It doesn't matter. connect(), connect(AF_UNSPEC), listen() gets to the
same state without a race. The tcp_bpf_clone() hunk is for such sockets.
>> + if (!is_insidevar(prot, tcp_bpf_prots))
>> + return;
>
> If sock_copy() copies the already-restored sk_prot alongside the
> not-yet-restored sk_data_ready or sk_write_space, won't
> is_insidevar(prot, tcp_bpf_prots) evaluate to false in tcp_bpf_clone(),
> leaving the child socket with the psock callbacks and allowing the same
> unbounded self-recursion if the child is later added to a sockmap?
The window is there, but it's tiny and it's not from this patch.
> How does a socket that transitions from TCP_ESTABLISHED to TCP_LISTEN while
> remaining in a sockmap wake up accept() when new connections arrive?
It doesn't. It's an old bug, not from this patch.
next prev parent reply other threads:[~2026-11-02 0:17 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-01 19:20 [PATCH bpf 00/15] bpf, sockmap: Fixes for verdicts, redirects, corks and recvmsg() Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 01/15] bpf, sockmap: Write sg.start when recvmsg() faults Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 02/15] bpf, sockmap: Don't let an SK_DROP verdict stick Alexei Starovoitov
2026-11-01 19:39 ` bot+bpf-ci
2026-11-02 0:15 ` Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 03/15] bpf, sockmap: Don't let an SK_PASS verdict cover the next message Alexei Starovoitov
2026-11-01 19:42 ` sashiko-bot
2026-11-02 0:16 ` Alexei Starovoitov
2026-11-01 19:51 ` bot+bpf-ci
2026-11-01 19:20 ` [PATCH bpf 04/15] bpf, sockmap: Subtract all dropped bytes from the return value Alexei Starovoitov
2026-11-01 19:39 ` bot+bpf-ci
2026-11-01 19:20 ` [PATCH bpf 05/15] bpf, sockmap: Clear the resume state of a stopped psock Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 06/15] bpf, sockmap: Give no progs to a TCP listener Alexei Starovoitov
2026-11-01 19:51 ` sashiko-bot
2026-11-02 0:17 ` Alexei Starovoitov [this message]
2026-11-01 19:20 ` [PATCH bpf 07/15] bpf, sockmap: Check the target of an egress redirect before each send Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 08/15] net: Leave sk_stream_wait_memory() once the socket is dead Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 09/15] bpf, sockmap: Check the TCP state in recvmsg() Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 10/15] bpf, sockmap: Reset the copy position when corking Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 11/15] bpf, sockmap: Don't copy 0 bytes into a full cork Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 12/15] bpf, sockmap: Clear the redirect target before the sk_msg prog runs Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 13/15] bpf, sockmap: Check that the redirected message is the cork Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 14/15] bpf, sockmap: Keep the rest of the cork after a redirect Alexei Starovoitov
2026-11-01 19:20 ` [PATCH bpf 15/15] bpf, sockmap: Clear the end mark of elements added by push and pop Alexei Starovoitov
2026-11-01 21:30 ` [PATCH bpf 00/15] bpf, sockmap: Fixes for verdicts, redirects, corks and recvmsg() MPTCP CI
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=DMKAKRM51QKN.34OI7DN57OAV7@gmail.com \
--to=alexei.starovoitov@gmail.com \
--cc=bpf@vger.kernel.org \
--cc=mptcp@lists.linux.dev \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.