netdev - Re: [RFC] mark devices with broken LRO implementation

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: <20101206.092855.193714367.davem@davemloft.net>
Date:	Mon, 06 Dec 2010 09:28:55 -0800 (PST)
From:	David Miller <davem@...emloft.net>
To:	olof@...om.net
Cc:	shemminger@...tta.com, leitao@...ux.vnet.ibm.com,
	eli@....mellanox.co.il, netdev@...r.kernel.org
Subject: Re: [RFC] mark devices with broken LRO implementation

From: Olof Johansson <olof@...om.net>
Date: Mon, 6 Dec 2010 11:18:16 -0600

> On Mon, Dec 06, 2010 at 09:10:10AM -0800, Stephen Hemminger wrote:
>> The kernel uses dev_disable_lro to disable Large Receive Offload
>> for cases where it is inappropriate. But several drivers do not implement
>> the required hook.  This is a "penalty box" patch to encourage those
>> drivers to add support for the necessary ethtool set_flags.
>> 
>> Signed-off-by: Stephen Hemminger <shemminger@...tta.com>
> 
> pasemi_mac:
> 
> Acked-by: Olof Johansson <olof@...om.net>
> 
>> I only found three drivers that are broken. Normally, I would just fix
>> them; but since changing state in the device is hardware specific, and
>> I don't have the hardware or specs to do anything useful to fix it.
> 
> Thanks. All my hardware is currently in storage due to my relocation, but
> I'll take a look at it when I have something to run on back. :-)

I don't think we can do what this patch does.

It serves no purpose, as it just means the user is going to have an
extra headache to turn their driver on.

And %99 of them won't see it, the distribution folks will.

So this is all for nothing.

Better to just work on fixing the problem in the few drivers for
which the issue exists.

And I'm always happy to receive patches that just plain rip LRO
support out of such drivers.  That's a real legitimate patch unlike
this one because it keeps the user able to get their driver enabled
with no fuss and it removes only the improperly functioning feature.
--
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