Tue, Sep 20, 2016 at 04:32:53PM CEST, vivien.dide...@savoirfairelinux.com wrote: >Hi Andrew, Russell, > >Andrew Lunn <and...@lunn.ch> writes: > >> 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. >> >> 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. > >It looks similar to when a switchdev object/attribute is added/deleted >without the SWITCHDEV_F_DEFER flag, used in the bridge code to defer >switchdev operations until switchdev_deferred_process() is called. > >This is usually used to process switchdev ops outside the bridge lock. > >Jiri, can switchdev_port_vlan_fill not using SWITCHDEV_F_DEFER be the >reason for this suspicious RCU usage when issuing "bridge vlan show"?
If it is called from atomic context, it should be deferred. > >Thanks, > > Vivien
