netdev - Re: [PATCH 1/8] e1000e: cleanup several stats issues

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <48164C02.9060902@intel.com>
Date:	Mon, 28 Apr 2008 15:13:22 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Jeff Garzik <jeff@...zik.org>
CC:	Auke Kok <auke-jan.h.kok@...el.com>, netdev@...r.kernel.org,
	e1000-devel@...ts.sourceforge.net
Subject: Re: [PATCH 1/8] e1000e: cleanup several stats issues

Jeff Garzik wrote:
> Auke Kok wrote:
>> From: Bruce Allan <bruce.w.allan@...el.com>
>>
>> Several stats registers are completely unused and we just waste pci
>> bus time reading them. We also omit using the high 32 bits of the GORC/
>> GOTC counters. We can just read clear them and only read the low
>> registers.
>>
>> Mii-tool can also break es2lan if it executes a MII PHY register
>> ioctl while the device is in autonegotiation. Unfortunately it seems
>> that several applications and installations still perform this ioctl
>> call periodically and especially in this crucial startup time. We
>> can fool the ioctl by providing fail safe information that mimics
>> the "down" link state and only perform the dangerous PHY reads once
>> after link comes up to fill in the real values. As long as link
>> stays up the information will not change.
>>
>> Signed-off-by: Bruce Allan <bruce.w.allan@...el.com>
>> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@...el.com>
>> Signed-off-by: Jesse Brandeburg <jesse.brandeburg@...el.com>
>> Signed-off-by: Auke Kok <auke-jan.h.kok@...el.com>
> 
> applied 1-8
> 
> I was mainly waiting for the discussion of the abuse of the ethtool
> interface, which I chose to allow.
> 
> Now, send me a patch to the ethtool man page for this new behavior :)

it almost seems more appropriate to send a patch to the e1000 README and explain
the parameter use in there since this is a per-driver modification and there's
nothing special about the ethtool call itself.

Would you be OK with a general patch to ethtool that states that "drivers may
interpret values differently and users should consult the driver's source code or
README for proper use of the parameter." ?

This seems the logical solution.

Auke

--
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