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]

Message-ID: <CANP3RGdjmgm10rH4AZAVt8Zx+MjwKkzxZ6hoJYuYmQXEz25qQg@mail.gmail.com>
Date:	Thu, 21 Mar 2013 13:47:07 -0700
From:	Maciej Żenczykowski <maze@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	Dmitry Kravkov <dkravkov@...il.com>,
	Eric Dumazet <eric.dumazet@...il.com>,
	Linux NetDev <netdev@...r.kernel.org>,
	Dmitry Kravkov <dmitry@...adcom.com>,
	Eilon Greenstein <eilong@...adcom.com>,
	Pravin B Shelar <pshelar@...ira.com>,
	Hsiao-keng Jerry Chu <hkchu@...gle.com>
Subject: Re: [PATCH net-next] gro: relax ID check in inet_gro_receive()

> We have very reasonable requirements for segmentation offloads

I would tend to disagree with reversibility being a reasonable requirement.
It offers extremely little benefit, and thus it's a nice to have at best.
However, I do understand why you might want it, and thus I can
understand why you might not want to accept this patch (which would
make GRO less reversible).

This logic does not apply to the GRE segmentation offload patches.
They might create non incrementing IP ID packet sequences on the wire,
and this may prevent GRO from kicking in, but it does not make TSO
non-reversible
(if anything it makes it easy to detect that it happened).

Would you perhaps be willing to take a patch which simply removes the
flag from the driver features?
But leaves the code in?
--
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