netdev - Re: [e1000e] BUG triggered when triggering LED blinking

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: <alpine.WNT.2.00.1011101030130.14720@jbrandeb-desk1.amr.corp.intel.com>
Date:	Wed, 10 Nov 2010 10:32:52 -0800 (Pacific Standard Time)
From:	"Brandeburg, Jesse" <jesse.brandeburg@...el.com>
To:	Holger Eitzenberger <holger@...zenberger.org>
cc:	"e1000-devel@...ts.sourceforge.net" 
	<e1000-devel@...ts.sourceforge.net>,
	"netdev@...r.kernel.org" <netdev@...r.kernel.org>
Subject: Re: [e1000e] BUG triggered when triggering LED blinking



On Tue, 9 Nov 2010, Holger Eitzenberger wrote:

> Hi,
> 
> using e1000e driver version 1.2.10 and kernel version 2.6.32.24 I see
> the kernel go BUG() sporadically at the time 'ethtool -p eth0 3' comes
> back.
> 
> Network hardware is four times 'Intel Corporation 82583V Gigabit Network
> Connection' (0x8086:0x150c) on Atom N450.
> 
> kernel BUG at kernel/workqueue.c:287!

<snip>

> 
> The full trace is attached, it may become clearer from that.
> 
> After taking a look I think this may be caused by initializing
> adapter->led_blink_task several times in e1000_phys_id(), while possibly
> led_blink_task is running:
> 
> 	if ((hw->phy.type == e1000_phy_ife) ||
> 	    (hw->mac.type == e1000_pchlan) ||
> 	    (hw->mac.type == e1000_82574)) {
> 		INIT_WORK(&adapter->led_blink_task, e1000e_led_blink_task);
> 		if (!adapter->blink_timer.function) {
> 
> I can't reproduce it after moving it inside the following if block,
> but I'm not quite sure if this catches all races in there.  Especially
> the msleep_interruptible() may be too optimistic because it may
> actually not wait long enough.  Someone with more knowledge of the
> driver should take a look.

thanks for your investigation and troubleshooting.  I don't think it is 
correct at all to be calling INIT_WORK more than once.  In fact the 
INIT_WORK should just be moved into probe, and then e1000_phys_id should 
just do schedule_work.


--
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