From: Jeff Moyer <jmoyer@redhat.com>
To: Mitch Williams <mitch.a.williams@intel.com>
Cc: "Kok, Auke-jan H" <auke-jan.h.kok@intel.com>,
Matt Mackall <mpm@selenic.com>,
"Garzik, Jeff" <jgarzik@pobox.com>,
Neil Horman <nhorman@tuxdriver.com>,
netdev@vger.kernel.org, "Brandeburg,
Jesse" <jesse.brandeburg@intel.com>,
"Kok, Auke" <auke@foo-projects.org>
Subject: Re: [PATCH 1/2] e1000: fix netpoll with NAPI
Date: Thu, 08 Jun 2006 13:29:00 -0400 [thread overview]
Message-ID: <x49ac8nwo83.fsf@redhat.com> (raw)
In-Reply-To: <1149787174.2928.3.camel@strongmad> (Mitch Williams's message of "Thu, 08 Jun 2006 10:19:34 -0700")
==> Regarding Re: [PATCH 1/2] e1000: fix netpoll with NAPI; Mitch Williams <mitch.a.williams@intel.com> adds:
mitch.a.williams> On Wed, 2006-06-07 at 11:44 -0700, Jeff Moyer wrote:
>> That patch locks around the tx clean routine. As such, it doesn't
>> prevent the problem.
mitch.a.williams> The call to netif_rx_schedule_prep provides locking
mitch.a.williams> because it sets the __LINK_STATE_RX_SCHED bit atomically.
mitch.a.williams> The spinlock around e1000_clean_tx_irq is to protect it
mitch.a.williams> from other calls to the transmit routine, not NAPI.
Yes, but what prevents recursion in the poll routine? Consider that the
poll routine could end up triggerring a printk (think iptables, here). In
that case, you end up calling into netpoll, and if the tx ring is full, we
call the poll_controller routine. We've now recursed.
The poll lock was originally introduced to prevent recursion, not
concurrent access.
-Jeff
next prev parent reply other threads:[~2006-06-08 17:23 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-05 23:09 [PATCH 0/2] e1000: fixes for netpoll+NAPI, ARM Kok, Auke
2006-06-05 23:11 ` [PATCH 1/2] e1000: fix netpoll with NAPI Kok, Auke
2006-06-06 13:52 ` Neil Horman
2006-06-06 16:39 ` Mitch Williams
2006-06-06 17:05 ` Neil Horman
2006-06-06 17:18 ` Auke Kok
2006-06-06 17:30 ` Jeff Moyer
2006-06-06 17:34 ` Auke Kok
2006-06-06 17:42 ` Jeff Moyer
2006-06-06 23:17 ` Matt Mackall
2006-06-07 15:05 ` Neil Horman
2006-06-07 16:48 ` Matt Mackall
2006-06-07 18:25 ` Auke Kok
2006-06-07 18:44 ` Jeff Moyer
2006-06-07 19:18 ` Neil Horman
2006-06-08 17:19 ` Mitch Williams
2006-06-08 17:29 ` Jeff Moyer [this message]
2006-06-12 0:13 ` Neil Horman
2006-06-12 16:42 ` Mitch Williams
2006-06-12 18:06 ` Neil Horman
2006-06-14 20:41 ` Neil Horman
2006-06-14 23:44 ` Mitch Williams
2006-06-15 12:44 ` John W. Linville
2006-06-15 20:45 ` Mitch Williams
2006-06-20 8:28 ` Andrew Grover
2006-06-07 18:54 ` John W. Linville
2006-06-08 17:23 ` Mitch Williams
2006-06-08 18:39 ` John W. Linville
2006-06-06 17:29 ` Jeff Moyer
2006-06-05 23:11 ` [PATCH 2/2] e1000: remove risky prefetch on next_skb->data Kok, Auke
2006-06-05 23:21 ` Rick Jones
2006-06-06 0:12 ` Brandeburg, Jesse
2006-06-06 0:16 ` Rick Jones
2006-06-06 0:22 ` Andi Kleen
2006-06-06 0:26 ` Brandeburg, Jesse
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=x49ac8nwo83.fsf@redhat.com \
--to=jmoyer@redhat.com \
--cc=auke-jan.h.kok@intel.com \
--cc=auke@foo-projects.org \
--cc=jesse.brandeburg@intel.com \
--cc=jgarzik@pobox.com \
--cc=mitch.a.williams@intel.com \
--cc=mpm@selenic.com \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.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.