netdev - Re: [PATCH] gianfar: Fix crashes on RX path (Was Re: [Bugme-new] [Bug 19692] New: linux-2.6.36-rc5 crash with gianfar ethernet at full line rate traffic)

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:	Fri, 22 Oct 2010 07:03:26 +0000
From:	Jarek Poplawski <jarkao2@...il.com>
To:	Eric Dumazet <eric.dumazet@...il.com>
Cc:	emin ak <eminak71@...il.com>, David Miller <davem@...emloft.net>,
	Andrew Morton <akpm@...ux-foundation.org>,
	netdev@...r.kernel.org, bugzilla-daemon@...zilla.kernel.org,
	bugme-daemon@...zilla.kernel.org,
	Anton Vorontsov <avorontsov@...sta.com>,
	Andy Fleming <afleming@...escale.com>
Subject: Re: [PATCH] gianfar: Fix crashes on RX path (Was Re: [Bugme-new]
	[Bug 19692] New: linux-2.6.36-rc5 crash with gianfar ethernet at
	full line rate traffic)

On Fri, Oct 22, 2010 at 08:14:08AM +0200, Eric Dumazet wrote:
> Le vendredi 22 octobre 2010 ?? 08:42 +0300, emin ak a écrit :
> > Hi Jarek;
> > 
> > > Maybe for now let's try to get and see this type 1 again? Since the
> > > recycle path is suspicious a bit to me, probably limiting memory or
> > > slowing tx (maybe different mtus on eth0 and 1) under heavy multi cpu
> > > load might help.
> > >
> > 
> > I'll do my best with your recommended test conditions. I have reserved
> > a machine and two ports of  hw packet generator, now we'll see if this
> > error will occur again or not. (But I'am not sure if I want to see it
> > again:)
> 
> Really this rx recycle affair is more than suspicious to me too.
> 
> Is it really worth the pain ?
> 
> Are MTU changes handled correctly ? ( must flush rx_recycle queue...)
> 
> Using a single rx_recycle queue in a supposed multiqueue driver makes
> absolutely _no_ sense to me. This adds an artificial contention point.
> 

Yes, the design/need of this rx_recycle queue should be reconsidered.
But we don't know if the (other?) bug seen by Emin was connected, so
it would be better to try to reproduce it without too many changes.

Jarek P.
--
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