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: <20070522012227.GD11401@redhat.com>
Date:	Mon, 21 May 2007 21:22:27 -0400
From:	Dave Jones <davej@...hat.com>
To:	"Kok, Auke" <auke-jan.h.kok@...el.com>
Cc:	Herbert Xu <herbert.xu@...hat.com>, jeff@...zik.org,
	stable@...r.kernel.org, greg@...e.de,
	e1000-devel@...ts.sourceforge.net, netdev@...r.kernel.org
Subject: Re: [PATCH] e1000: Don't enable polling in open() (was: e1000: assertion hit in e1000_clean(), kernel 2.6.21.1)

On Mon, May 21, 2007 at 05:58:27PM -0700, Kok, Auke wrote:
 > >> This probably doesn't solve the latter bug.
 > >> The code you reference isn't there in the kernel tested in that bug
 > >> (2.6.21)   In 2.6.21, netif_poll_enable is only called from
 > >> e1000_up(), not e1000_open()
 > > 
 > > Yes we need a different fix for 2.6.21.  There e1000_open calls
 > > e1000_up which is why we still get the netif_poll_enable.
 > 
 > yes, basically they need the patch that introduced(exposed) the problem as well, 
 > but that is a rather significant change and kind of moves the whole 
 > netstack-init code in e1000 around. The size was the reason why that patch 
 > didn't go into 2.6.21 in the first place, but perhaps they can pull both patches 
 > into the FC tree.
 > 
 > For reference, this is the commit:
 > 
 > commit e0aac5a289b1dacbc94bd9ae8c449bcdf9ab508c
 > Author: Auke Kok <auke-jan.h.kok@...el.com>
 > Date:   Tue Mar 6 08:57:21 2007 -0800
 > 
 >      e1000: FIX: be ready for incoming irq at pci_request_irq
 > 
 >      DEBUG_SHIRQ code exposed that e1000 was not ready for incoming interrupts
 >      after having called pci_request_irq. This obviously requires us to finish
 >      our software setup which assigns the irq handler before we request the
 >      irq.
 > 
 >      Signed-off-by: Auke Kok <auke-jan.h.kok@...el.com>
 >      Signed-off-by: Jeff Garzik <jeff@...zik.org>
 > 
 > Dave, would that be an option for you?

Sounds like a plan.  I'll do a test-build with this and the other
patch, and throw it at the people seeing the problem tomorrow.

Thanks,

	Dave

-- 
http://www.codemonkey.org.uk
-
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