netdev - Re: [PATCH net-next] net: core: allow fast GRO for skbs with Ethernet header in head

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: <20191114.172508.1027995193093100862.davem@davemloft.net>
Date:   Thu, 14 Nov 2019 17:25:08 -0800 (PST)
From:   David Miller <davem@...emloft.net>
To:     alobakin@...nk.ru
Cc:     ecree@...arflare.com, jiri@...lanox.com, edumazet@...gle.com,
        idosch@...lanox.com, pabeni@...hat.com, petrm@...lanox.com,
        sd@...asysnail.net, f.fainelli@...il.com,
        jaswinder.singh@...aro.org, manishc@...vell.com,
        GR-Linux-NIC-Dev@...vell.com, johannes.berg@...el.com,
        emmanuel.grumbach@...el.com, luciano.coelho@...el.com,
        linuxwifi@...el.com, kvalo@...eaurora.org, netdev@...r.kernel.org,
        linux-wireless@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH net-next] net: core: allow fast GRO for skbs with
 Ethernet header in head

From: Alexander Lobakin <alobakin@...nk.ru>
Date: Tue, 12 Nov 2019 15:28:43 +0300

> Commit 78d3fd0b7de8 ("gro: Only use skb_gro_header for completely
> non-linear packets") back in May'09 (2.6.31-rc1) has changed the
> original condition '!skb_headlen(skb)' to the current
> 'skb_mac_header(skb) == skb_tail_pointer(skb)' in gro_reset_offset()
> saying: "Since the drivers that need this optimisation all provide
> completely non-linear packets".

Please reference the appropriate SHA1-ID both here in this paragraph and
also in an appropriate Fixes: tag.

If this goes so far back that it is before GIT, then you need to provide
a reference to the patch posting via lore.kernel.org or similar because
it is absolutely essentialy for people reviewing this patch to be able
to do some digging into why the condition is code the way that it is
currently.

Thank you.