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.

>        Vivien

Reply via email to