Subject: Re: NAPI note

From: Manfred Spraul <[email-masked]>
Date: Tue, 18 Feb 2003 17:31:20 +0100

David S. Miller wrote:

>   From: Jeff Garzik <[email-masked]>
>   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