From: Ben Hutchings <ben@decadent.org.uk>
To: "Li, Zhen-Hua" <zhen-hual@hp.com>
Cc: "David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Veaceslav Falico <vfalico@redhat.com>,
Nicolas Dichtel <nicolas.dichtel@6wind.com>,
Jiri Pirko <jiri@resnulli.us>,
stephen hemminger <stephen@networkplumber.org>,
Jerry Chu <hkchu@google.com>,
Sathya Perla <sathya.perla@emulex.com>,
Subbu Seetharaman <subbu.seetharaman@emulex.com>,
Ajit Khaparde <ajit.khaparde@emulex.com>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 1/1] net: Add rtnl_lock for netif_device_attach/detach
Date: Tue, 22 Apr 2014 18:26:36 +0100 [thread overview]
Message-ID: <1398187596.7767.60.camel@deadeye.wl.decadent.org.uk> (raw)
In-Reply-To: <1397632082-18453-1-git-send-email-zhen-hual@hp.com>
[-- Attachment #1: Type: text/plain, Size: 3091 bytes --]
On Wed, 2014-04-16 at 15:08 +0800, Li, Zhen-Hua wrote:
> From: "Li, Zhen-Hua" <zhen-hual@hp.com>
>
> As netif_running is called in netif_device_attach/detach. There should be
> rtnl_lock/unlock called, to avoid dev stat change during netif_device_attach
> and detach being called.
> I checked NIC some drivers, some of them have netif_device_attach/detach
> called between rtnl_lock/unlock, while some drivers do not.
>
> This patch is tring to find a generic way to fix this for all NIC drivers.
I don't think you can generically use the RTNL lock for this.
> Signed-off-by: Li, Zhen-Hua <zhen-hual@hp.com>
> ---
> net/core/dev.c | 18 ++++++++++++++++++
> 1 file changed, 18 insertions(+)
>
> diff --git a/net/core/dev.c b/net/core/dev.c
> index 5b3042e..795bbc5 100644
> --- a/net/core/dev.c
> +++ b/net/core/dev.c
> @@ -2190,10 +2190,19 @@ EXPORT_SYMBOL(__dev_kfree_skb_any);
> */
> void netif_device_detach(struct net_device *dev)
> {
> + /**
> + * As netif_running is called , rtnl_lock and unlock are needed to
> + * avoid __LINK_STATE_START bit changes during this function call.
> + */
> + int need_unlock;
> +
> + need_unlock = rtnl_trylock();
It is never correct to use trylock and then continue even if it fails.
I think you're trying to simulate a reentrant mutex but this will fail
if *any* task already has the mutex.
Furthermore it is currently allowed and useful to call these functions
from atomic context (transmit or completion path) where it is not
possible to hold the mutex.
> if (test_and_clear_bit(__LINK_STATE_PRESENT, &dev->state) &&
> netif_running(dev)) {
> netif_tx_stop_all_queues(dev);
> }
> + if (need_unlock)
> + rtnl_unlock();
> }
> EXPORT_SYMBOL(netif_device_detach);
For netif_device_detach(), I wonder whether it is necessary to check
netif_running(). What are we trying to avoid?
> @@ -2205,11 +2214,20 @@ EXPORT_SYMBOL(netif_device_detach);
> */
> void netif_device_attach(struct net_device *dev)
> {
> + /**
> + * As netif_running is called , rtnl_lock and unlock are needed to
> + * avoid __LINK_STATE_START bit changes during this function call.
> + */
> + int need_unlock;
> +
> + need_unlock = rtnl_trylock();
> if (!test_and_set_bit(__LINK_STATE_PRESENT, &dev->state) &&
> netif_running(dev)) {
> netif_tx_wake_all_queues(dev);
> __netdev_watchdog_up(dev);
> }
> + if (need_unlock)
> + rtnl_unlock();
> }
> EXPORT_SYMBOL(netif_device_attach);
I do see a problem if netif_device_detach() races with
dev_deactivate_many(), which is being mitigated but not avoided by the
test of netif_running().
I think a proper solution is going to involve changing
dev_deactivate_many() as well, removing the use of netif_running(), and
possible using cmpxchg() to atomically manipulate multiple bits of
dev->state.
Ben.
--
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 811 bytes --]
prev parent reply other threads:[~2014-04-22 17:26 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 7:08 Li, Zhen-Hua
2014-04-16 7:38 ` Veaceslav Falico
2014-04-16 8:34 ` Li, ZhenHua
2014-04-18 19:01 ` Sergei Shtylyov
2014-04-21 6:30 ` Li, ZhenHua
2014-04-21 11:54 ` Sergei Shtylyov
2014-04-22 17:26 ` Ben Hutchings [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=1398187596.7767.60.camel@deadeye.wl.decadent.org.uk \
--to=ben@decadent.org.uk \
--cc=ajit.khaparde@emulex.com \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=hkchu@google.com \
--cc=jiri@resnulli.us \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nicolas.dichtel@6wind.com \
--cc=sathya.perla@emulex.com \
--cc=stephen@networkplumber.org \
--cc=subbu.seetharaman@emulex.com \
--cc=vfalico@redhat.com \
--cc=zhen-hual@hp.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
all inboxes | Powered by JetHome®