David S. Miller wrote:
From: Jeff Garzik <jgarzik@xxxxxxxxx>
Date: Fri, 14 Feb 2003 18:58:13 -0500
Manfred Spraul wrote:
> It seems to be a generic NAPI restriction:
> The caller of netif_receive_skb() must not own a spinlock that is
> acquired from an interrupt handler.
Thanks much for noticing this, Manfred.
I think this logic is buggy.
In the example I've seen posted, only a NAPI implementation bug
could cause the situation to occur.
If cpu1 is in ->poll() for the driver, then by definition the
device shall not cause interrupts. The device's interrupts
are disabled before we enter the ->poll() handler, and as such
the "cpu2 take device interrupt and takes driver->lock" cannot
occur.
No. I think the rule is that drivers that use the NAPI interface must
not cause interrupts for packet receive and out-of-rx-buffers conditions.
But what about media error interrupts, or tx interrupts? Or MIB counter
overflow, etc. What about shared pci interrupts?
All of them could occur, and if they take a spinlock that is held across
netif_receive_skb(), then it can deadlock.
OTHO if it's guaranteed that no interrupt occurs, then the nic should
not take a spinlock at all and rely on the synchronization provided by
NAPI. (->poll is single-threaded).
--
Manfred
|