mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Daniel Zahka" <daniel.zahka@gmail.com>
To: <patchwork-bot+netdevbpf@kernel.org>,
	"Daniel Zahka" <daniel.zahka@gmail.com>
Cc: <kuba@kernel.org>, <willemdebruijn.kernel@gmail.com>,
	<davem@davemloft.net>, <edumazet@google.com>, <pabeni@redhat.com>,
	<horms@kernel.org>, <andrew+netdev@lunn.ch>,
	<netdev@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH net-next 0/4] psp: make tx key ops optional for drivers
Date: Tue, 08 Sep 2026 10:09:56 -0400	[thread overview]
Message-ID: <DL9ZTV87UI2A.2QIEPTDS2ROKA@gmail.com> (raw)
In-Reply-To: <178882561539.3212362.10949911837502586488.git-patchwork-notify@kernel.org>

On Mon Sep 7, 2026 at 8:00 PM EDT, patchwork-bot+netdevbpf wrote:
> Hello:
>
> This series was applied to netdev/net-next.git (main)
> by Jakub Kicinski <kuba@kernel.org>:
>
> On Thu, 03 Sep 2026 18:33:58 -0700 you wrote:
>> This is the first of two series which together implement rekeying PSP
>> protected tcp connections. Here are both series together on github:
>> https://github.com/danieldzahka/linux/commits/psp-rekey-split/
>> 
>> This first series is mostly non-functional changes, except for the minor
>> difference that netdevsim driver implements tx key ops. Its tx key ops
>> were basically NOPs, and in the future PSP core can subsume the assoc
>> counting that it was doing.
>> 
>> [...]
>
> Here is the summary with links:
>   - [net-next,1/4] psp: refactor psp_dev_tx_key_del()
>     https://git.kernel.org/netdev/net-next/c/7b26ff200739
>   - [net-next,2/4] psp: move code from psp_sock_assoc_set_tx() into helper functions
>     https://git.kernel.org/netdev/net-next/c/4d3a7d1104eb
>   - [net-next,3/4] psp: allow drivers to omit tx key add/del ops
>     https://git.kernel.org/netdev/net-next/c/1e16b303109f
>   - [net-next,4/4] netdevsim: psp: drop tx key ops
>     https://git.kernel.org/netdev/net-next/c/da630d1da2b1
>
> You are awesome, thank you!

Thanks. I think applying was the right move, but I would like to
highlight something that sashiko flagged on patch 4, as I think it will
need to be addressed with its own series. The hazard is preexisting and
much broader than the way sashiko talks about it. 

The high level idea is that netdev core should probably take extra care
to make sure users of sk_validate_xmit_skb (psp and ktls) cannot clobber
what each other has set for that callback. In the case of psp vs. ktls,
there are probably fundamental reasons why these should be kept mutually
exclusive and their uapis should reject attempts to transition between
them.

More generally however, any offloads wishing to claim
sk_validate_xmit_skb should be considered mutually exclusive, and netdev
core may benefit from a generic system to enforce ownership. That would
help in case another user of sk_validate_xmit_skb comes along later.

  reply	other threads:[~2026-09-08 14:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-04  1:33 Daniel Zahka
2026-09-04  1:33 ` [PATCH net-next 1/4] psp: refactor psp_dev_tx_key_del() Daniel Zahka
2026-09-06 17:08   ` Willem de Bruijn
2026-09-04  1:34 ` [PATCH net-next 2/4] psp: move code from psp_sock_assoc_set_tx() into helper functions Daniel Zahka
2026-09-06 17:09   ` Willem de Bruijn
2026-09-04  1:34 ` [PATCH net-next 3/4] psp: allow drivers to omit tx key add/del ops Daniel Zahka
2026-09-06 17:09   ` Willem de Bruijn
2026-09-04  1:34 ` [PATCH net-next 4/4] netdevsim: psp: drop tx key ops Daniel Zahka
2026-09-06 17:09   ` Willem de Bruijn
2026-09-08  0:00 ` [PATCH net-next 0/4] psp: make tx key ops optional for drivers patchwork-bot+netdevbpf
2026-09-08 14:09   ` Daniel Zahka [this message]
2026-09-08 17:33     ` Jakub Kicinski
2026-09-08 18:58       ` Daniel Zahka

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=DL9ZTV87UI2A.2QIEPTDS2ROKA@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=linux-kernel@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=pabeni@redhat.com \
    --cc=patchwork-bot+netdevbpf@kernel.org \
    --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®