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]
Message-ID: <20101022070326.GB7036@ff.dom.local>
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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ