netdev - Re: [PATCH net-next v2 3/8] udp: properly complete L4 GRO over UDP tunnel packet

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+FuTSd3b+oRkf+6hkZqYwwrAqM7rOgj8GDcz5LgwXCEvNLW7Q@mail.gmail.com>
Date:   Fri, 26 Mar 2021 13:51:38 -0400
From:   Willem de Bruijn <willemdebruijn.kernel@...il.com>
To:     Paolo Abeni <pabeni@...hat.com>
Cc:     Network Development <netdev@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        Steffen Klassert <steffen.klassert@...unet.com>,
        Alexander Lobakin <alobakin@...me>
Subject: Re: [PATCH net-next v2 3/8] udp: properly complete L4 GRO over UDP
 tunnel packet

On Thu, Mar 25, 2021 at 1:24 PM Paolo Abeni <pabeni@...hat.com> wrote:
>
> After the previous patch, the stack can do L4 UDP aggregation
> on top of a UDP tunnel.
>
> In such scenario, udp{4,6}_gro_complete will be called twice. This function
> will enter its is_flist branch immediately, even though that is only
> correct on the second call, as GSO_FRAGLIST is only relevant for the
> inner packet.
>
> Instead, we need to try first UDP tunnel-based aggregation, if the GRO
> packet requires that.
>
> This patch changes udp{4,6}_gro_complete to skip the frag list processing
> when while encap_mark == 1, identifying processing of the outer tunnel
> header.
> Additionally, clears the field in udp_gro_complete() so that we can enter
> the frag list path on the next round, for the inner header.
>
> v1 -> v2:
>  - hopefully clarified the commit message
>
> Signed-off-by: Paolo Abeni <pabeni@...hat.com>

Reviewed-by: Willem de Bruijn <willemb@...gle.com>