netdev - Re: DSA and underlying 802.1Q encapsulation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <5566A10F.8060603@roeck-us.net>
Date:	Wed, 27 May 2015 22:01:03 -0700
From:	Guenter Roeck <linux@...ck-us.net>
To:	Andrew Lunn <andrew@...n.ch>
CC:	Vivien Didelot <vivien.didelot@...oirfairelinux.com>,
	netdev <netdev@...r.kernel.org>,
	Florian Fainelli <f.fainelli@...il.com>,
	Chris Healy <cphealy@...il.com>,
	Jérome Oufella 
	<jerome.oufella@...oirfairelinux.com>
Subject: Re: DSA and underlying 802.1Q encapsulation

On 05/27/2015 06:46 PM, Andrew Lunn wrote:
> On Wed, May 27, 2015 at 03:51:59PM -0700, Guenter Roeck wrote:
>> 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.
>
> It looks like DSA needs to implement ndo_get_lock_subclass().
>
> We can probably copy the code from macvlan.c.
>

Not entirely, but I think I have an idea. I'll give it a try.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html