From: Stephen Hemminger <shemminger@osdl.org>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: Michael Buesch <mb@bu3sch.de>,
bcm43xx-dev@lists.berlios.de, netdev@vger.kernel.org,
Stefano Brivio <st3@riseup.net>
Subject: Re: netdev tx timeouts
Date: Thu, 14 Sep 2006 11:21:40 +0900 [thread overview]
Message-ID: <20060914112140.192e980a@localhost.localdomain> (raw)
In-Reply-To: <4508B892.4040309@lwfinger.net>
On Wed, 13 Sep 2006 21:04:02 -0500
Larry Finger <Larry.Finger@lwfinger.net> wrote:
> Stephen Hemminger wrote:
> > On Wed, 13 Sep 2006 15:49:23 +0200
> > Michael Buesch <mb@bu3sch.de> wrote:
> >> Simple. Reading the code of synchronize_net() and
> >> netif_stop_queue() and thinking about why it breaks, instead
> >> of committing bugfixes that only substitute one bug by another. ;)
> >> I'll take a look, too.
> >
> > Why are you doing the synchronize_net()? it is meant for RCU.
>
> We know and it no longer is in the code. We have known for a couple of days that
> it was the synchronize_net() step that led to the netdev timeouts, but we were
> afraid that a bare netif_stop_queue would not be SMP safe. The current structure has
>
> mutex_lock
> netif_tx_disable(dev) (equivalent to netif_tx_lock_bh(dev);
> netif_stop_queue(dev);
> netif_tx_unlock_bh(dev);
> spin_lock_irqsafe
>
> I see you listed as a maintainer in several network-related parts of the system,
> so AFAIK, you are a network guru. Do you think this will work? I have tested
> code with just a netif_stop_queue (without the lock_bh/unlock_bh parts) on a UP
> system and have gotten no errors, but I do not have access to SMP hardware.
>
> Thanks,
>
I haven't done a careful review of the broadcom driver. What you
are proposing looks fine. But most network devices just use spin_lock's
rather than mutexs because there is little need for holding the lock
for a long length of time.
>
next prev parent reply other threads:[~2006-09-14 2:21 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-09-13 2:25 netdev tx timeouts Larry Finger
[not found] ` <45076C00.2000100-tQ5ms3gMjBLk1uMJSBkQmQ@public.gmane.org>
2006-09-13 12:30 ` Michael Buesch
[not found] ` <200609131430.53820.mb-fseUSCV1ubazQB+pC5nmwQ@public.gmane.org>
2006-09-13 13:25 ` Larry Finger
2006-09-13 13:49 ` Michael Buesch
2006-09-13 14:12 ` Michael Buesch
2006-09-14 1:23 ` Stephen Hemminger
[not found] ` <20060914102337.137d4591-bi+AKbBUZKY6gyzm1THtWbp2dZbC/Bob@public.gmane.org>
2006-09-14 2:04 ` Larry Finger
2006-09-14 2:21 ` Stephen Hemminger [this message]
2006-09-14 2:35 ` Larry Finger
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=20060914112140.192e980a@localhost.localdomain \
--to=shemminger@osdl.org \
--cc=Larry.Finger@lwfinger.net \
--cc=bcm43xx-dev@lists.berlios.de \
--cc=mb@bu3sch.de \
--cc=netdev@vger.kernel.org \
--cc=st3@riseup.net \
/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).