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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).