netdev - RE: [PATCH net-next] be2net: Ignore spurious UE indication from NIC

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]

Date:	Wed, 26 Sep 2012 22:35:14 +0000
From:	"Khaparde, Ajit" <Ajit.Khaparde@...lex.Com>
To:	David Miller <davem@...emloft.net>
CC:	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: RE: [PATCH net-next] be2net: Ignore spurious UE indication from NIC

> From: David Miller [davem@...emloft.net]
> Sent: Friday, September 21, 2012 2:04 PM
> To: Khaparde, Ajit
> Cc: netdev@...r.kernel.org
> Subject: Re: [PATCH net-next] be2net: Ignore spurious UE indication from NIC
>
> From: Ajit Khaparde <ajit.khaparde@...lex.com>
> Date: Fri, 21 Sep 2012 11:36:20 -0500
>
>> Ignore spurious UE indication seen on some platforms.
>> Consider the error as un-recoverable only when the bits
>> stay high during second sampling.
>>
>> Signed-off-by: Ajit Khaparde <ajit.khaparde@...lex.com>
>
> Treating uncorrectable errors as spurious seems like an invitation
> for hard to track down data corruption to me.
>
> You'll need to come up with a more sophisticated test for
> spurious other than "happens more than once" before I'm willing
> to subject the entire world to this kind of potential problem.

If the UE is real, then the hardware will stop responding to requests.
The hardware block goes offline automatically and no traffic will flow.
After this the hardware will generate a register dump, which can be
retrived using ethtool.

A spurious UE or a data corruption will not generate this dump.

The detection logic is merely to inform the user about the failure
and also avoid any further access to the NIC. This will also prevent
the driver unload from having to timeout on each access to the hardware
which could take a long time to complete.

Please let me know if this is enough to differentiate the scenarios.

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