[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aS1ZdbElmUB7VyPU@secunet.com>
Date: Mon, 1 Dec 2025 10:01:41 +0100
From: Steffen Klassert <steffen.klassert@...unet.com>
To: Cosmin Ratiu <cratiu@...dia.com>
CC: <netdev@...r.kernel.org>, Jay Vosburgh <jv@...sburgh.net>, Andrew Lunn
<andrew+netdev@...n.ch>, "David S. Miller" <davem@...emloft.net>, Eric
Dumazet <edumazet@...gle.com>, Jakub Kicinski <kuba@...nel.org>, Paolo Abeni
<pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Taehee Yoo
<ap420073@...il.com>, Jianbo Liu <jianbol@...dia.com>, Sabrina Dubroca
<sd@...asysnail.net>, Herbert Xu <herbert@...dor.apana.org.au>, Leon
Romanovsky <leonro@...dia.com>
Subject: Re: [RFC PATCH ipsec 0/2] Fix bonding IPSec races
On Fri, Nov 21, 2025 at 05:16:42PM +0200, Cosmin Ratiu wrote:
> These patches are an alternate proposed fix to the bonding IPSec races
> which could result in unencrypted IPSec packets on the wire.
> I'm sending them as RFC based on the discussion with Sabrina on the
> primary approach [1].
>
> [1] https://lore.kernel.org/netdev/20251113104310.1243150-1-cratiu@nvidia.com/T/#u
>
> Cosmin Ratiu (2):
> xfrm: Add explicit offload_handle to some xfrm callbacks
> bonding: Maintain offloaded xfrm on all devices
>
> Documentation/networking/xfrm_device.rst | 13 +-
> drivers/net/bonding/bond_main.c | 284 ++++++++++--------
> .../net/ethernet/chelsio/cxgb4/cxgb4_main.c | 20 +-
> .../inline_crypto/ch_ipsec/chcr_ipsec.c | 25 +-
> .../net/ethernet/intel/ixgbe/ixgbe_ipsec.c | 47 +--
> drivers/net/ethernet/intel/ixgbevf/ipsec.c | 18 +-
> .../marvell/octeontx2/nic/cn10k_ipsec.c | 13 +-
> .../mellanox/mlx5/core/en_accel/ipsec.c | 26 +-
> .../net/ethernet/netronome/nfp/crypto/ipsec.c | 10 +-
> drivers/net/netdevsim/ipsec.c | 8 +-
> include/linux/netdevice.h | 7 +-
> include/net/bonding.h | 22 +-
> net/xfrm/xfrm_device.c | 3 +-
> net/xfrm/xfrm_state.c | 7 +-
> 14 files changed, 295 insertions(+), 208 deletions(-)
There are only minor changes to the IPsec subsystem,
compared to drivers and bonding. Also this is a rather
big change for a fix. So if this patchset should go to
the ipsec tree, we would need some ACKs from the drivers
an bonding maintainers.
Powered by blists - more mailing lists