netdev - Re: [PATCH v4 2/2] bnx2x: disable GSO where gso

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]

Date:   Wed, 31 Jan 2018 13:43:11 -0800
From:   Eric Dumazet <eric.dumazet@...il.com>
To:     Daniel Axtens <dja@...ens.net>, netdev@...r.kernel.org
Cc:     Manish.Chopra@...ium.com, Jason Wang <jasowang@...hat.com>,
        Pravin Shelar <pshelar@....org>,
        Marcelo Ricardo Leitner <marcelo.leitner@...il.com>
Subject: Re: [PATCH v4 2/2] bnx2x: disable GSO where gso_size is too big for
 hardware

On Wed, 2018-01-31 at 14:15 +1100, Daniel Axtens wrote:
> If a bnx2x card is passed a GSO packet with a gso_size larger than
> ~9700 bytes, it will cause a firmware error that will bring the card
> down:
> 
> bnx2x: [bnx2x_attn_int_deasserted3:4323(enP24p1s0f0)]MC assert!
> bnx2x: [bnx2x_mc_assert:720(enP24p1s0f0)]XSTORM_ASSERT_LIST_INDEX 0x2
> bnx2x: [bnx2x_mc_assert:736(enP24p1s0f0)]XSTORM_ASSERT_INDEX 0x0 = 0x00000000 0x25e43e47 0x00463e01 0x00010052
> bnx2x: [bnx2x_mc_assert:750(enP24p1s0f0)]Chip Revision: everest3, FW Version: 7_13_1
> ... (dump of values continues) ...
> 
> Detect when the mac length of a GSO packet is greater than the maximum
> packet size (9700 bytes) and disable GSO.
> 
> Signed-off-by: Daniel Axtens <dja@...ens.net>
> 
> ---
> 
> v4: Only call the slow check if the gso_size is large.
>     Eric - I think this is what you had in mind?
>     Manish - do you think this is an acceptable performance trade-off?
>              GSO will work for any packet size, and only jumbo frames will
> 	     have to do the slower test.

Yes this looks good to me, thanks !

Reviewed-by: Eric Dumazet <edumazet@...gle.com>