netdev - Re: REGRESSION: panic on e1000 driver

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]

Date:	Wed, 30 May 2007 21:51:14 -0700
From:	"Kok, Auke" <auke-jan.h.kok@...el.com>
To:	Herbert Xu <herbert@...dor.apana.org.au>
CC:	Doug Chapman <doug.chapman@...com>, netdev@...r.kernel.org,
	e1000-devel@...ts.sourceforge.net
Subject: Re: REGRESSION: panic on e1000 driver

Herbert Xu wrote:
> On Wed, May 30, 2007 at 03:57:13PM -0700, Kok, Auke wrote:
>> Hmm, we're making a mess of it.
> 
> Indeed :)
> 
>> Herbert, wouldn't it just have been a lot easier to do just add a 
>> netif_poll_disable in e1000_probe, so that any and all other poll 
>> enable/disables are symmetric ? Something like this?
> 
> I wish if it were as simple as that.  As soon as register_netdev
> returns somebody else can invoke e1000_open so disabling poll
> here can be undesirable.  In fact the existing netif_stop_queue
> and netif_carrier_off calls are also bad for the same reason.

this has been an age-old confusion that I never grasped either, so I perfectly 
understand why you added the explicit e1000_disable_irq call in the other patch 
(and think thats a great idea). But really, there should be a way for a driver 
to tell the stack that it should really keep it's hands off :)

BTW e1000 currently triggers a single irq manually in the watchdog as link goes 
up, so that might be the one that is giving problems now. In any case I can't 
reproduce any of it - perhaps my hardware is too fast. Time to whip out the pIII :o

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