netdev - Re: [patch 03/14] e1000: omit stats for broken counter in 82543

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: <4582B62F.9020705@garzik.org>
Date:	Fri, 15 Dec 2006 09:50:23 -0500
From:	Jeff Garzik <jeff@...zik.org>
To:	Arjan van de Ven <arjan@...ux.intel.com>
CC:	netdev@...r.kernel.org, "Kok, Auke" <auke-jan.h.kok@...el.com>,
	John Ronciak <john.ronciak@...el.com>,
	Jeff Kirsher <jeffrey.t.kirsher@...el.com>
Subject: Re: [patch 03/14] e1000: omit stats for broken counter in 82543

Arjan van de Ven wrote:
> Jeff Garzik wrote:
>> Needs to use an "i have broken stats" feature flag, rather than adding 
>> yet another mac_type test into the code.  This testing of MAC type 
>> rather than feature flags is a major e1000 problem, and it bloats the 
>> driver quite a bit.  Intel has been told for /months/ this is a 
>> problem, yet I still see patches like this.
>>
> it is "nice" that you say this, and Intel is working on a "flags" based 
> driver. However that is, as you state yourself here, a major invasive 
> change, and thus not suitable for 2.6.20 inclusion. Yet these fixes are 
> important bugfixes; I don't think it's fair to hold these hostage..

Completely false.  I /never/ said it was a major invasive change.

The following is obviously /not/ an invasive change, but rather a simple 
incremental approach:

1) Define "unsigned long flags" in your adapter struct
(only has to be done once)

2) For the management patch (patch #3?), define a flag 
E1000_FLG_I_HAVE_MGMT.

3) Set this flag everywhere patch #3 does a mac_type test.  Appears to 
be 2-4 locations TOUCHED BY THE PATCH ANYWAY.

4) Watch the patch get applied.

Shall I do this for Intel, since this has been explained multiple times 
without success?  This is not an invasive approach, it only touches what 
code you were touching anyway.

A WORD OF WARNING:  I am also highly suspicious of impending driver 
rewrites.  Such massive events inevitably break 'git bisect'.  A far 
better approach is the Al Viro equivalent-transformation approach, which 
does not break 'git bisect' and can be easily verified by a human.

	Jeff

-
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