netdev - Re: [PATCH net-next] gro: relax ID check in inet_gro

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:	Thu, 21 Mar 2013 14:56:27 -0400 (EDT)
From:	David Miller <davem@...emloft.net>
To:	dkravkov@...il.com
Cc:	eric.dumazet@...il.com, netdev@...r.kernel.org,
	dmitry@...adcom.com, eilong@...adcom.com, pshelar@...ira.com,
	hkchu@...gle.com, maze@...gle.com
Subject: Re: [PATCH net-next] gro: relax ID check in inet_gro_receive()

From: Dmitry Kravkov <dkravkov@...il.com>
Date: Thu, 21 Mar 2013 20:11:37 +0200

>> Well, I suspect this hardware is not capable of doing the proper ID
>> manipulation twice. (inner and outer header)
> 
> This is correct: ID only for one of the headers can be handled with
> current FW/HW, for other DF is set.

DF does not matter.

Regardless of DF, we must set the ID field correctly.

It is abundantly clear that the current GRE tunnel segmentation
is not generating packets according to our well documented
rules, in that we must be able to precisely create exactly
the original packet stream from the segmented frame.

Someone needs to send me patches to revert the bnx2x GRE segmentation
support, and any software implementation in our tree that has the same
bug.

If someone doesn't do it, I will revert all of this code myself.  You
simply will have to cope with not having this optimization until
your hardware can do it properly and according to our well established
rules for segmentation offloads.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html