mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Daniel Zahka" <daniel.zahka@gmail.com>
To: <netdev-bot+sashiko@kernel.org>, <daniel.zahka@gmail.com>
Cc: <edumazet@google.com>, <ncardwell@google.com>,
	<kuniyu@google.com>, <davem@davemloft.net>, <kuba@kernel.org>,
	<pabeni@redhat.com>, <horms@kernel.org>,
	<willemdebruijn.kernel@gmail.com>, <andrew+netdev@lunn.ch>,
	<shuah@kernel.org>, <willemb@google.com>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
	<linux-kselftest@vger.kernel.org>
Subject: Re: [PATCH net 1/2] net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb()
Date: Tue, 15 Sep 2026 15:17:52 -0400	[thread overview]
Message-ID: <DLG4RGGCZ776.1UU67KP7TWDAH@gmail.com> (raw)
In-Reply-To: <178917294180.219967.2431474539892551274@kernel.org>

On Fri Sep 11, 2026 at 8:29 PM EDT, netdev-bot+sashiko wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential
> issue(s) to consider:
>
> Critical: 0 · High: 0 · Medium: 1 · Low: 0
>
> - [Medium] The new mutual-exclusion gate keys off
>   `sk->sk_validate_xmit_skb`, a function pointer that is inherited…
>
> --
>
> net: psp: avoid conflicts with skb->decrypted and sk_validate_xmit_skb()
>
> This adds a mutual exclusion gate so that a socket cannot carry both PSP
> state and a TCP ULP, since the two conflict over skb->decrypted and
> sk->sk_validate_xmit_skb(). The gate is applied in __tcp_set_ulp() and in
> psp_sock_assoc_set_rx().
>
>> diff --git a/include/net/sock.h b/include/net/sock.h
>> index 51185222aac29..ba5e5092f192c 100644
>> --- a/include/net/sock.h
>> +++ b/include/net/sock.h
>> @@ -2312,6 +2312,17 @@ static inline void sk_gso_disable(struct sock *sk)
>>  	sk->sk_route_caps &= ~NETIF_F_GSO_MASK;
>>  }
>>  
>> +static inline bool sk_has_validate_xmit_skb(const struct sock *sk)
>> +{
>> +#ifdef CONFIG_SOCK_VALIDATE_XMIT
>> +	return !!sk->sk_validate_xmit_skb;
>> +#else
>> +	return false;
>> +#endif
>> +}
>
> [Severity: Medium]
> Is sk_validate_xmit_skb a reliable indicator of live per-socket state here?
> The field sits after sk_dontcopy_end in struct sock, so sock_copy() copies
> it verbatim into a cloned socket, and neither sk_clone() nor
> inet_csk_clone_lock() resets it.  By contrast, sk_clone() does explicitly
> clear the PSP association:
>
> net/core/sock.c:sk_clone() {
> 	sock_copy(newsk, sk);
> 	...
> #if IS_ENABLED(CONFIG_INET_PSP)
> 	RCU_INIT_POINTER(newsk->psp_assoc, NULL);
> #endif
>
> So a socket accepted from a listener that had PSP Tx state installed ends up
> with sk_validate_xmit_skb == psp_validate_xmit while psp_assoc == NULL, and
> sk_has_validate_xmit_skb() then reports true for a child that has neither a
> PSP association nor a ULP.
>

Sorry, I started a response based on viewing this report in the clashiko
web app, but then realized after I had sent it that I had received the
report in email form. For the record my response is here:
https://lore.kernel.org/netdev/DLCXDVPGGC8M.11EBKPBY2KNVP@gmail.com/

So, is this a blocker to merge this as is? I could drop the check on
sk->sk_validtate_xmit_sbk to appease sashiko, but in my opinion this
makes the patch worse. My ultimate goal is to defeature psp assoc
operations on non TCP_ESTABLISHED sockets in a way similar to tls ulp.

  reply	other threads:[~2026-09-15 19:17 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-10 23:46 [PATCH net 0/2] " Daniel Zahka
2026-09-10 23:46 ` [PATCH net 1/2] " Daniel Zahka
2026-09-12  0:29   ` netdev-bot+sashiko
2026-09-15 19:17     ` Daniel Zahka [this message]
2026-09-12  0:53   ` Daniel Zahka
2026-09-10 23:46 ` [PATCH net 2/2] selftests: drv-net: psp: test PSP and TCP ULP mutual exclusion Daniel Zahka
2026-09-11 10:57   ` Daniel Zahka
2026-09-11 20:00     ` Matthieu Baerts

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=DLG4RGGCZ776.1UU67KP7TWDAH@gmail.com \
    --to=daniel.zahka@gmail.com \
    --cc=andrew+netdev@lunn.ch \
    --cc=davem@davemloft.net \
    --cc=edumazet@google.com \
    --cc=horms@kernel.org \
    --cc=kuba@kernel.org \
    --cc=kuniyu@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=ncardwell@google.com \
    --cc=netdev-bot+sashiko@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=shuah@kernel.org \
    --cc=willemb@google.com \
    --cc=willemdebruijn.kernel@gmail.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®