netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Stephen Hemminger <shemminger@linux-foundation.org>
To: Olaf Kirch <okir@lst.de>
Cc: David Miller <davem@davemloft.net>, netdev@vger.kernel.org
Subject: Re: Races in net_rx_action vs netpoll?
Date: Thu, 19 Jul 2007 17:27:47 +0100	[thread overview]
Message-ID: <20070719172747.7f01b38e@oldman.hamilton.local> (raw)
In-Reply-To: <200707191719.21034.okir@lst.de>

On Thu, 19 Jul 2007 17:19:19 +0200
Olaf Kirch <okir@lst.de> wrote:

> On Thursday 12 July 2007 04:33, David Miller wrote:
> > I'll add merge your patch with a target of 2.6.23
> > 
> > If you really want, after this patch has sat in 2.6.23 for a while
> > and got some good testing, we can consider a submission for -stable.
> 
> Okay, those of you who followed the discussion on lkml will have
> read why this patch breaks on e1000.
> 
> Short summary: some NIC drivers expect that there is a one-to-one
> relation between calls to net_rx_schedule (where we put the device
> on the poll list) and netif_rx_complete (where it's supposed to be
> taken off the list). The e1000 is such a beast. Not sure if other
> drivers make the same assumption re NAPI.
> 
> So: should a driver be allowed to rely on this behavior? Or should
> I go and look for another fix to the poll_napi issue?
> 
> I keep coming back to the question Jarek asked - why does netpoll
> want to call dev->poll() anyway? I dug around a little and it
> seems the original idea was to do this only if netpoll_poll was
> running on the CPU the netdevice was scheduled to.
> 
> So one way to fix the problem is to add a dev->poll_cpu field
> that tells us on which CPU's poll list it has been added - and
> check for this in poll_napi.
> 
> Comments?

Please revisit the requirements that netconsole needs and redesign it
from scratch.  The existing code  is causing too much breakage. 

Can it be done without breaking the semantics of network
devices, or should we rewrite the driver interface to take have a different
interface like netdev_sync_send_skb()  that is slow, synchronous and 
non-interrupt (ie polls for completion).  Of course, then people will complain
that netconsole traffic slows the machine down.
for completion.

> David, should I submit an updated patch for 2.6.23, or do you
> prefer to yank the patch now and try again for 2.6.24?
> 
> Olaf
> -- 
> Olaf Kirch  |  --- o --- Nous sommes du soleil we love when we play
> okir@lst.de |    / | \   sol.dhoop.naytheet.ah kin.ir.samse.qurax
> -
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

  reply	other threads:[~2007-07-19 16:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-04 12:16 Races in net_rx_action vs netpoll? Olaf Kirch
2007-07-09 22:27 ` David Miller
2007-07-10 10:44   ` Olaf Kirch
2007-07-11  5:44     ` David Miller
2007-07-11  7:41       ` Olaf Kirch
2007-07-12  2:33         ` David Miller
2007-07-19 15:19           ` Olaf Kirch
2007-07-19 16:27             ` Stephen Hemminger [this message]
2007-07-22  7:05               ` David Miller
2007-07-24 10:26                 ` Jarek Poplawski
2007-07-12 12:59     ` Jarek Poplawski
2007-07-12 13:54       ` Olaf Kirch
2007-07-13  8:55         ` Jarek Poplawski
2007-07-16  8:06           ` Jarek Poplawski

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=20070719172747.7f01b38e@oldman.hamilton.local \
    --to=shemminger@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=netdev@vger.kernel.org \
    --cc=okir@lst.de \
    /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).