netdev - Re: [PATCH net-next 05/15] ipv6/gso: remove temporary HBH/jumbo header

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <802be507c28b9c1815e6431e604964b79070cd40.camel@gmail.com>
Date:   Thu, 03 Feb 2022 13:08:36 -0800
From:   Alexander H Duyck <alexander.duyck@...il.com>
To:     Eric Dumazet <edumazet@...gle.com>
Cc:     Eric Dumazet <eric.dumazet@...il.com>,
        "David S . Miller" <davem@...emloft.net>,
        Jakub Kicinski <kuba@...nel.org>,
        netdev <netdev@...r.kernel.org>, Coco Li <lixiaoyan@...gle.com>
Subject: Re: [PATCH net-next 05/15] ipv6/gso: remove temporary HBH/jumbo
 header

On Thu, 2022-02-03 at 11:59 -0800, Eric Dumazet wrote:
> On Thu, Feb 3, 2022 at 11:45 AM Alexander Duyck
> <alexander.duyck@...il.com> wrote:
> 
> > It is the fact that you are adding IPv6 specific code to the
> > net/core/skbuff.c block here. Logically speaking if you are adding the
> > header in ipv6_gro_receive then it really seems li:ke the logic to
> > remove the header really belongs in ipv6_gso_segment. I suppose this
> > is an attempt to optimize it though, since normally updates to the
> > header are done after segmentation instead of before.
> 
> Right, doing this at the top level means we do the thing once only,
> instead of 45 times if the skb has 45 segments.

I'm just wondering if there is a way for us to do it in
ipv6_gso_segment directly instead though. With this we essentially end
up having to free the skb if the segmentation fails anyway since it
won't be able to go out on the wire.

If we assume the stack will successfully segment the frame then it
might make sense to just take care of the hop-by-hop header before we
start processing the L4 protocol.