From: Mitch Williams <mitch.a.williams@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: "Kok, Auke" <auke-jan.h.kok@intel.com>,
"Garzik, Jeff" <jgarzik@pobox.com>,
netdev@vger.kernel.org, "Brandeburg,
Jesse" <jesse.brandeburg@intel.com>,
"Kok, Auke" <auke@foo-projects.org>,
jmoyer@redhat.com, mpm@selenic.com
Subject: Re: [PATCH 1/2] e1000: fix netpoll with NAPI
Date: Tue, 06 Jun 2006 09:39:25 -0700 [thread overview]
Message-ID: <1149611965.13635.19.camel@strongmad> (raw)
In-Reply-To: <20060606135217.GA21969@hmsreliant.homelinux.net>
On Tue, 2006-06-06 at 09:52 -0400, Neil Horman wrote:
> I've been speaking about this fix with a Jeff Moyer, and we've come up with some
> concerns regarding its implementation. Specifically the call to
> adapter->clean_rx in the case of the e1000 driver is rather a layering
> violation in the netpoll code, in the sense that the function pointed to by clean_rx
> is functionality that is nominally used by the dev->poll method. In fact in
> this case, it would appear possible since dev->poll is called under the
> poll_lock, but dev->poll_controller is not, that is is possible to have cpus in
> a system executing in e1000_clean_rx_irq_[ps] at the same time leading to data
> corruption:
>
> CPU0:
> netpoll_poll_dev
> dev->poll_controller (e1000_netpoll)
> adapter->clean_rx (e1000_clean_rx_irq)
>
> CPU1:
> napi_poll
> dev->poll (e1000_clean)
> e1000_clean_rx_irq
Hmmm. You may have a point. I don't think a spinlock is required, but
we do need to check if the poll is already scheduled on another CPU,
like netpoll does in poll_napi().
In practice, of course, we never see this. The only netpoll client in
the kernel is netconsole, which doesn't do receives. A few Major
Distros use netdump, which does do receives, but only after the system
has crashed. In that case, all other CPUs are stopped anyway.
However, just for the sake of correctness (and paranoia), I'll whip up
another patch that does this check.
Jeff, please do not commit this patch.
-Mitch
NB: The root of this problem is that e1000 uses a dummy netdev to
schedule NAPI polling. Since netpoll doesn't know about the dummy
netdev, it checks the "real" e1000 netdev struct to see if it's
scheduled for polling. Since this is never the case, netpoll fails when
e1000 is configured to use NAPI. Hence, this patch.
Why is the dummy netdev in place? To support multi-queue RX. Our PCIe
adapters support this, but the kernel's not _quite_ ready yet.
Hopefully, the VJ net channel stuff will enable this feature.
next prev parent reply other threads:[~2006-06-06 16:42 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 [this message]
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
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=1149611965.13635.19.camel@strongmad \
--to=mitch.a.williams@intel.com \
--cc=auke-jan.h.kok@intel.com \
--cc=auke@foo-projects.org \
--cc=jesse.brandeburg@intel.com \
--cc=jgarzik@pobox.com \
--cc=jmoyer@redhat.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.