netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Miller <davem@davemloft.net>
To: eric.dumazet@gmail.com
Cc: michael.chan@broadcom.com, netdev@vger.kernel.org
Subject: Re: [PATCH net] net: Fix inconsistent rtnl_lock usage on dev_get_stats().
Date: Fri, 06 Jan 2017 13:01:34 -0500 (EST)	[thread overview]
Message-ID: <20170106.130134.50153126758574257.davem@davemloft.net> (raw)
In-Reply-To: <1483723976.9712.19.camel@edumazet-glaptop3.roam.corp.google.com>

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Fri, 06 Jan 2017 09:32:56 -0800

> This makes no sense to me.
> 
> RTNL is absolutely not needed to get device stats.
> 
> We try to not add RTNL, especially when not required.
> 
> Sure, RTNETLINK dumps currently hold RTNL, but we had various attempts
> in the past to get rid of this behavior.
> 
> If a device driver expects RTNL being locked, it is clearly a bug that
> needs a fix anyway.

This is extremely problematic when the driver has to synchronize some
piece of state between the get stats method and open/close.  It is
exactly the case we are trying to solve in tg3, and lots of drivers
end up hitting the same exact issue.

If open/close can happen asynchronously to get stats, it is very hard
to make dynamically allocated data structures or DMA buffers usable
from the stats call.

Drivers in this situation will just add a mutex specifically for this
situation if we don't consistently apply RTNL locking here.

  reply	other threads:[~2017-01-06 18:01 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-01-06  4:21 [PATCH net] net: Fix inconsistent rtnl_lock usage on dev_get_stats() Michael Chan
2017-01-06 11:19 ` [net] bf7d953378: BUG:sleeping_function_called_from_invalid_context_at_kernel/locking/mutex.c kernel test robot
2017-01-06 17:32 ` [PATCH net] net: Fix inconsistent rtnl_lock usage on dev_get_stats() Eric Dumazet
2017-01-06 18:01   ` David Miller [this message]
2017-01-06 19:30     ` Michael Chan
2017-01-06 20:13     ` Eric Dumazet
2017-01-08  2:03       ` David Miller

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=20170106.130134.50153126758574257.davem@davemloft.net \
    --to=davem@davemloft.net \
    --cc=eric.dumazet@gmail.com \
    --cc=michael.chan@broadcom.com \
    --cc=netdev@vger.kernel.org \
    /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).