lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <aQM90v2J9maIvTlU@krikkit>
Date: Thu, 30 Oct 2025 11:28:34 +0100
From: Sabrina Dubroca <sd@...asysnail.net>
To: Steffen Klassert <steffen.klassert@...unet.com>
Cc: Jianbo Liu <jianbol@...dia.com>, netdev@...r.kernel.org,
	davem@...emloft.net, kuba@...nel.org,
	Cosmin Ratiu <cratiu@...dia.com>,
	Herbert Xu <herbert@...dor.apana.org.au>,
	Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
	Simon Horman <horms@...nel.org>, David Ahern <dsahern@...nel.org>
Subject: Re: [PATCH ipsec v3 2/2] xfrm: Determine inner GSO type from packet
 inner protocol

2025-10-30, 09:08:11 +0100, Steffen Klassert wrote:
> On Tue, Oct 28, 2025 at 04:04:36PM +0100, Sabrina Dubroca wrote:
> > 2025-10-28, 21:36:17 +0800, Jianbo Liu wrote:
> > > 
> > > My proposed plan is:
> > > 
> > > Send the patch 1 and patch 3 (including the xfrm_ip2inner_mode change)
> > > together to the ipsec tree. They are self-contained fixes.
> > 
> > So, keep v3 of this series unchanged.
> > 
> > > Separately, after those are accepted, I can modify and re-submit that patch
> > > [1] to ipsec-next that removes the now-redundant checks from the other
> > > callers (VTI, etc.), leveraging the updated helper function.
> > > 
> > > This way, the critical fixes are self-contained and backportable, while the
> > > cleanup of other callers happens later in the development cycle.
> > 
> > The only (small) drawback is leaving the duplicate code checking
> > AF_UNSPEC in the existing callers of xfrm_ip2inner_mode, but I guess
> > that's ok.
> > 
> > 
> > Steffen, is it ok for you to
> > 
> >  - have a duplicate AF_UNSPEC check in callers of xfrm_ip2inner_mode
> >    (the existing "default to x->inner_mode, call xfrm_ip2inner_mode if
> >    AF_UNSPEC", and the new one added to xfrm_ip2inner_mode by this
> >    patch) in the ipsec tree and then in stable?
> > 
> >  - do the clean up (like the diff I pasted in my previous email, or
> >    something smaller if [1] is applied separately) in ipsec-next after
> >    ipsec is merged into it?
> 
> I'm OK with this, I can take v3 as is.

Ok. In that case, you can add:

Reviewed-by: Sabrina Dubroca <sd@...asysnail.net>

for both patches.

Thanks.

-- 
Sabrina

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ