netdev - Re: [PATCH 2/3] myri10ge: limit the number of recoveries

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: <4662E481.4030508@garzik.org>
Date:	Sun, 03 Jun 2007 11:55:45 -0400
From:	Jeff Garzik <jeff@...zik.org>
To:	Brice Goglin <brice@...i.com>
CC:	netdev@...r.kernel.org
Subject: Re: [PATCH 2/3] myri10ge: limit the number of recoveries

Brice Goglin wrote:
> Limit the number of recoveries from a NIC hw watchdog reset to 1 by default.
> It enables detection of defective NICs immediately since these memory parity
> errors are expected to happen very rarely (less than once per century*NIC).
> However, a defective NIC (very rare, fortunately) can see such an error
> quite often, ie. every few minutes under high load.
> 
> Make the limit tunable to allow people with mission critical installations
> to crank up the tunable and recover an INTMAX number of times while waiting
> for a downtime window to replace the NIC. The performance won't be optimal,
> but at least, it will still work.
> 
> Signed-off-by: Brice Goglin <brice@...i.com>
> ---
>  drivers/net/myri10ge/myri10ge.c |   15 +++++++++++++--
>  1 file changed, 13 insertions(+), 2 deletions(-)

NAK.  Random broken (unrelated to silicon errata) can happen in any 
field installation, and manifest itself in any number of ways.

If defective NICs are truly rare, it does not sound worth adding this 
workaround to the driver.

If I had to guess, this is a meaningless gesture (from a technical 
standpoint) for a Big Customer(tm) who is currently throwing a 
temper-tantrum... :)

By definition if you can give them a patch, and they can wait for the 
driver patch going upstream, then it is not a "mission critical" 
situation, otherwise they would already have the patch direct from you. 
  Also, "mission critical" tends to imply that you cannot remove the 
driver from operation either, which is counter to the logic of patching 
a driver for the problem.

	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