netdev - Re: [PATCH net 3/3] r8169: increase the lifespan of the hardware counters dump area.

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: <20150908080512.GF20288@calimero.vinschen.de>
Date:	Tue, 8 Sep 2015 10:05:12 +0200
From:	Corinna Vinschen <vinschen@...hat.com>
To:	David Miller <davem@...emloft.net>
Cc:	romieu@...zoreil.com, netdev@...r.kernel.org,
	pomidorabelisima@...il.com
Subject: Re: [PATCH net 3/3] r8169: increase the lifespan of the hardware
 counters dump area.

Hi David,

On Sep  7 17:00, David Miller wrote:
> From: Corinna Vinschen <vinschen@...hat.com>
> Date: Mon, 7 Sep 2015 11:29:49 +0200
> 
> > Still wondering though.  Given that the driver never failed before if
> > the counter values couldn't be updated, and given that these counter
> > values only have statistical relevance, why should this suddenly result
> > in a fatal failure at open time?
> 
> Failing to allocate such a small buffer means we have much deeper issues
> at hand.  A GFP_KERNEL allocation of this size really should not fail.

I'm not talking about the allocation.  I agree with you on that score.

What I'm talking about is the situation where the NIC hardware fails to
reset or update its own counters for whatever reason.  Apparently the
mechanism is supposed to be performed within a given timeframe.  The
code sets some registers and then waits for a flag bit to be set to 0.
For that it utilizes a busy loop checking the flag bit up to 1000 times
with a delay of about 10 us.

The error condition is that the flag bit hasn't been set to 0 when the
loop exits, after roughly 10ms, and *this* part does not constitute a
fatal error which breaks the operation of the NIC.  So, from my
perspective a timeout while trying to wait for updated counter values
from the NIC at @ndo_open time should not be treated as fatal.

Corinna

Content of type "application/pgp-signature" skipped