From: Manfred Spraul <manfred@colorfullife.com>
To: "David S. Miller" <davem@redhat.com>
Cc: jgarzik@pobox.com, zaitcev@redhat.com, jbourne@mtroyal.ab.ca,
netdev@oss.sgi.com
Subject: Re: NAPI note
Date: Tue, 18 Feb 2003 17:31:20 +0100 [thread overview]
Message-ID: <3E525FD8.1060009@colorfullife.com> (raw)
In-Reply-To: <20030217.185719.28797590.davem@redhat.com>
David S. Miller wrote:
> From: Jeff Garzik <jgarzik@pobox.com>
> 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
next prev parent reply other threads:[~2003-02-18 16:31 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3E4D66DF.3040800@colorfullife.com>
2003-02-14 23:58 ` NAPI note (was Re: lockups with 2.4.20 (tg3? net/core/dev.c|deliver_to_old_ones)) Jeff Garzik
2003-02-18 2:57 ` NAPI note David S. Miller
2003-02-18 16:31 ` Manfred Spraul [this message]
2003-02-19 2:53 ` jamal
2003-02-19 3:14 ` Jeff Garzik
2003-02-19 3:18 ` David S. Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3E525FD8.1060009@colorfullife.com \
--to=manfred@colorfullife.com \
--cc=davem@redhat.com \
--cc=jbourne@mtroyal.ab.ca \
--cc=jgarzik@pobox.com \
--cc=netdev@oss.sgi.com \
--cc=zaitcev@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.