On 05/27/2015 02:05 PM, Andrew Lunn wrote:
Do you have lock debugging enabled in your code ? I am getting a recursive
lock warning due to a recursive call to dev_mc_sync(). I think we may have
to implement lock nesting for dsa, similar to how it id done for vlan
support, but I have not been able to figure out how exactly it works yet.
I might be able to help, since i solve two similar problems already in
DSA, one for MDIO bus, and a second one for transmit buffers.
Andrew
What I did is to create a vlan interface on one of the dsa slave ports
and enabling it.
This results in a call to dev_mc_sync() on the dsa interface, which is passed
on to the real interface. dev_mc_sync() calls netif_addr_lock_nested(to),
which results in the recursive lock message.
ifconfig/2291 is trying to acquire lock:
(_xmit_ETHER/1){+.....}, at: [<ffffffff8175b757>] dev_mc_sync+0x57/0xa0
but task is already holding lock:
(_xmit_ETHER/1){+.....}, at: [<ffffffff8175b757>] dev_mc_sync+0x57/0xa0
other info that might help us debug this:
Possible unsafe locking scenario:
CPU0
----
lock(_xmit_ETHER/1);
lock(_xmit_ETHER/1);
Pretty much inevitable as far as I can see.
Tentative solution would be to implement nesting as in the 802.1q code,
ie similar to vlan_dev_get_lock_subclass() and
vlan->nest_level = dev_get_nest_level(real_dev, is_vlan_dev) + 1;
but I am not sure on how to set nest_level.
Can we call dev_get_nest_level() with the Ethernet (cpu) interface as
parameter and add 1 ? If so, what should the second parameter evaluate ?
Or is there a better solution ?
Thanks,
Guenter
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
