All of lore.kernel.org
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@armlinux.org.uk>
To: Andrew Lunn <andrew@lunn.ch>, Dave Miller <davem@vger.kernel.org>,
	Eric Dumazet <edumazet@google.com>
Cc: netdev@vger.kernel.org,
	Vivien Didelot <vivien.didelot@savoirfairelinux.com>,
	"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
Subject: Re: DSA: Suspicious RCU usage (via rtnl_bridge_getlink)
Date: Tue, 20 Sep 2016 15:28:58 +0100	[thread overview]
Message-ID: <20160920142858.GP1041@n2100.armlinux.org.uk> (raw)
In-Reply-To: <20160920133833.GD20638@lunn.ch>

On Tue, Sep 20, 2016 at 03:38:33PM +0200, Andrew Lunn wrote:
> On Tue, Sep 20, 2016 at 11:26:12AM +0100, Russell King - ARM Linux wrote:
> > Issuing "bridge vlan show" on clearfog provokes a "suspicious RCU usage"
> > warning from the kernel (see below).
> > 
> > As it's illegal to schedule while holding the RCU read lock, there's the
> > possibility for this happening much earlier in the call sequence -
> > mv88e6xxx_port_vlan_dump() takes a mutex, and if that mutex were already
> > held, we'd schedule at that point.  The RCU read lock was taken by
> > rtnl_bridge_getlink().
> > 
> > It looks horrible to fix - mvmdio.c as well as DSA locking are involved.
> 
> Hi Russell
> 
> I would say this needs fixing higher up, in the bridge code. DSA has
> to be able to sleep, since the switch can be on any arbitrary bus,
> MDIO, SPI, etc. This will affect pure switchdev devices as well, since
> they often need to send a request to the switch and wait for a reply.

Hmm, okay, so looking around, other rtnl operations in there just
use for_each_netdev() or for_each_netdev_safe() without taking
any locks, apart from the rtnl mutex which we can see was already
taken.

Why does rtnl_bridge_getlink use RCU?  Can we drop the RCU read lock
and switch to using for_each_netdev() here?  Adding Dave and Eric,
as I guess they're more knowledgeable of the core rtnl code.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.

  reply	other threads:[~2016-09-20 14:29 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-20 10:26 DSA: Suspicious RCU usage (via rtnl_bridge_getlink) Russell King - ARM Linux
2016-09-20 13:38 ` Andrew Lunn
2016-09-20 14:28   ` Russell King - ARM Linux [this message]
2016-09-20 14:32   ` Vivien Didelot
2016-09-20 14:46     ` Jiri Pirko

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=20160920142858.GP1041@n2100.armlinux.org.uk \
    --to=linux@armlinux.org.uk \
    --cc=andrew@lunn.ch \
    --cc=davem@vger.kernel.org \
    --cc=edumazet@google.com \
    --cc=netdev@vger.kernel.org \
    --cc=paulmck@linux.vnet.ibm.com \
    --cc=vivien.didelot@savoirfairelinux.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.