netdev - Re: r8169 regression: UDP packets dropped intermittantly

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] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 22 Jun 2016 09:29:39 +0930
From:	Jonathan Woithe <jwoithe@...ad.com.au>
To:	Francois Romieu <romieu@...zoreil.com>
Cc:	netdev@...r.kernel.org
Subject: Re: r8169 regression: UDP packets dropped intermittantly

On Wed, Jun 22, 2016 at 01:09:57AM +0200, Francois Romieu wrote:
> Jonathan Woithe <jwoithe@...ad.com.au> :
> [...]
> > Is there any chance that this regression can be resolved?  It's been 6
> > months since the last contact was received from the list in relation to this
> > issue.  If the r8169 driver is to remain broken with respect to UDP traffic
> > then we will have no choice but to factor in a change in our standard
> > hardware for future systems.  Unfortunately this also means that dozens of
> > systems in the field cannot be upgraded to recent kernels since doing so
> > will trigger the regression.[1]
> 
> If I understood correctly (2015/11/21) you had a working system with a stock
> 4.2 or 4.3 kernel and the r8169.c from 1e874e041fc7c222cbd85b20c4406070be1f687a
> (i.e. da78dbff2e05630921c551dbbc70a4b7981a8fff "r8169: remove work from irq
> handler." parent) patched with the snippet below, right ?

Thanks for your response.

You are correct: that combination worked just fine.  From the response given
at the time it seemed that further follow-up work was on the way, so I was
puzzled when this didn't eventuate.

> If so, while not perfect, it should at least mitigate the "can't upgrade
> kernel" part.

Yes, it does do that.  I was under the impression that mainline could be
subsequently patched to fix the regression based on understandings gained
from the outcome of this workaround, but it seems that hasn't been possible
for some reason.  We would obviously prefer to ship unpatched kernels with
our systems since, among other things, it means we don't need to maintain an
out-of-tree patch (something which will only get more complex as internal
APIs evolve).  In addition, this approach does peg the r8169 driver in the
resulting system to 1e874e041fc7c222cbd85b20c4406070be1f68, which could have
implications for future debugging, other bug fixes and the like which come
later.

However, you are right in that with the cited patch we have a way to migrate
to something based on either 4.2 or 4.3 (at this point I haven't tested the
woraround combination with anything later).

> > If the decision has been made to leave the regression unfixed, please
> > let me know.
> 
> No such decision that I know of.

Does this mean that a patch to fix the regression will eventually be applied
to mainline (in which case I'll keep watching out for it)?  Or is the
out-of-tree workaround mentioned above considered to be the long term
fix for those who encounter the problem?

Regards
  jonathan