From: Ingo Molnar <mingo@kernel.org>
To: wangbiao <biao.wang@intel.com>
Cc: oneukum@suse.de, netdev@vger.kernel.org,
linux-usb@vger.kernel.org, linux-kernel@vger.kernel.org,
akpm@linux-foundation.org, mingo@elte.hu, a.p.zijlstra@chello.nl,
rusty@rustcorp.com.au, william.douglas@intel.com,
di.zhang@intel.com
Subject: Re: [PATCH V3] usbnet: fix race condition caused spinlock bad magic issue
Date: Thu, 14 Nov 2013 08:58:37 +0100 [thread overview]
Message-ID: <20131114075837.GA7292@gmail.com> (raw)
In-Reply-To: <1384394595.4229.24.camel@wangbiao>
* wangbiao <biao.wang@intel.com> wrote:
> @@ -86,6 +86,7 @@ static const char driver_name [] = "usbnet";
>
> /* use ethtool to change the level for any given device */
> static int msg_level = -1;
> +static spinlock_t dev_wait_lock = __SPIN_LOCK_UNLOCKED(dev_wait_lock);
> module_param (msg_level, int, 0);
> MODULE_PARM_DESC (msg_level, "Override default message level");
>
> @@ -1447,13 +1454,18 @@ static void usbnet_bh (unsigned long param)
> clear_bit(EVENT_RX_KILL, &dev->flags);
>
> // waiting for all pending urbs to complete?
Please escape this code from the clutches of C++ style!
> + spin_lock_irqsave(&dev_wait_lock, flags);
> if (dev->wait) {
> if ((dev->txq.qlen + dev->rxq.qlen + dev->done.qlen) == 0) {
> - wake_up (dev->wait);
> + wake_up(dev->wait);
> }
> + spin_unlock_irqrestore(&dev_wait_lock, flags);
> + return;
> + }
> + spin_unlock_irqrestore(&dev_wait_lock, flags);
The extra locking and the naked return from the middle of the
control flow is a bit sad.
>
> // or are we maybe short a few urbs?
> - } else if (netif_running (dev->net) &&
> + if (netif_running(dev->net) &&
> netif_device_present (dev->net) &&
> netif_carrier_ok(dev->net) &&
> !timer_pending (&dev->delay) &&
While using a global spinlock from the probe/teardown methods is
probably not a big deal, using it in usbnet_bh() looks rather
unfortunate for performance and scalability of this driver.
I don't know the usbnet code at all, but is there really no
natural per device synchronization method available for such
cases? Could the race be avoided some other way? How do other
drivers implement such kind of dev->wait handling?
Thanks,
Ingo
prev parent reply other threads:[~2013-11-14 7:58 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-14 2:03 [PATCH V3] usbnet: fix race condition caused spinlock bad magic issue wangbiao
2013-11-14 7:44 ` Oliver Neukum
[not found] ` <1384415082.18291.8.camel-B2T3B9s34ElbnMAlSieJcQ@public.gmane.org>
2013-11-14 9:18 ` Bjørn Mork
2013-11-14 7:58 ` Ingo Molnar [this message]
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=20131114075837.GA7292@gmail.com \
--to=mingo@kernel.org \
--cc=a.p.zijlstra@chello.nl \
--cc=akpm@linux-foundation.org \
--cc=biao.wang@intel.com \
--cc=di.zhang@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=oneukum@suse.de \
--cc=rusty@rustcorp.com.au \
--cc=william.douglas@intel.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).