netdev - Re: [PATCH v3 net-next 1/2] udp_tunnel: create a fastpath GRO lookup.

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: <67d078fa5b11e_2fc2f8294ed@willemb.c.googlers.com.notmuch>
Date: Tue, 11 Mar 2025 13:55:06 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Paolo Abeni <pabeni@...hat.com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>, 
 netdev@...r.kernel.org
Cc: "David S. Miller" <davem@...emloft.net>, 
 Eric Dumazet <edumazet@...gle.com>, 
 Jakub Kicinski <kuba@...nel.org>, 
 Simon Horman <horms@...nel.org>, 
 David Ahern <dsahern@...nel.org>, 
 kuniyu@...zon.com
Subject: Re: [PATCH v3 net-next 1/2] udp_tunnel: create a fastpath GRO lookup.

Paolo Abeni wrote:
> On 3/11/25 6:29 PM, Willem de Bruijn wrote:
> > Paolo Abeni wrote:
> >> On 3/11/25 3:32 AM, Willem de Bruijn wrote:
> >>> What about packets with a non-local daddr (e.g., forwarding)?
> >>
> >> I'm unsure if I understand the question. Such incoming packets at the
> >> GRO stage will match the given tunnel socket, either by full socket
> >> lookup or by dport only selection.
> >>
> >> If the GSO packet will be forwarded, it will segmented an xmit time.
> >>
> >> Possibly you mean something entirely different?!?
> > 
> > Thanks, no that is exactly what I meant:
> > 
> > Is a false positive possible? So answer is yes.
> > 
> > Is it safe. So, yes again, as further down the stack it just handles
> > the GSO packet correctly.
> > 
> > Would you mind adding that to commit message explicitly, since you're
> > respinning anyway?
> 
> I was confused because this patch does not change the current behaviour.

Oh right, this is also true of the existing __udp6_lib_lookup path.

> I'll add a note in v4.

Thanks