|To:||"David S. Miller" <davem@xxxxxxxxxx>|
|Subject:||Re: NAPI note|
|From:||Manfred Spraul <manfred@xxxxxxxxxxxxxxxx>|
|Date:||Tue, 18 Feb 2003 17:31:20 +0100|
|Cc:||jgarzik@xxxxxxxxx, zaitcev@xxxxxxxxxx, jbourne@xxxxxxxxxxxxx, netdev@xxxxxxxxxxx|
|References:||<3E4D66DF.3040800@xxxxxxxxxxxxxxxx> <3E4D8295.2050400@xxxxxxxxx> <20030217.185719.28797590.davem@xxxxxxxxxx>|
|User-agent:||Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021202|
David S. Miller wrote:
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.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.
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).
|<Prev in Thread]||Current Thread||[Next in Thread>|