On Tue, Jan 12, 2010 at 12:08:04AM -0800, David Miller wrote:

From: Jarek Poplawski <redacted>
Date: Tue, 12 Jan 2010 07:50:59 +0000

quoted

I think, I can see similar problems e.g. in gianfar or netxen, where
napi_disable() is done after netif_device_detach(), especially in
suspend procedures (there might be less severe (than oops) effects
yet). IMHO, it all looks simply error prone (sometime you have to
know a driver well to track all possible paths to say it's really
safe).

Then that's an even larger bug.

Until you do napi_disable(), the device can be touched.

Asynchronous paths outside of the driver's control, even
with interrupts disabled, can call back into the driver
and touch the chip.

F.e. netpoll via netconsole output on another cpu

So it therefore must be done before doing the actual work of bringing
the device down or suspending it.

Maybe I miss something, but once more: this patch mentioned by Berck
Nash has been tested by at least two users, Berck himself, and
probably even more intensively by Michael Breuer, during af_packet
debugging. Both guys acknowledged it helped, so it can't be that bad.

Jarek P.