netdev - Re: mlx5e throwing RTNL_ASSERT error on vxlan_get_rx

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] [day] [month] [year] [list]

Message-ID: <0088d4e8-5303-4714-f46b-b783534725f5@redhat.com>
Date:	Mon, 25 Apr 2016 11:07:12 +0200
From:	Hannes Frederic Sowa <hannes@...hat.com>
To:	Saeed Mahameed <saeedm@....mellanox.co.il>,
	Alexander Duyck <alexander.duyck@...il.com>
Cc:	Saeed Mahameed <saeedm@...lanox.com>,
	David Miller <davem@...emloft.net>,
	Netdev <netdev@...r.kernel.org>,
	Matthew Finlay <matt@...lanox.com>,
	Yevgeny Petrilin <yevgenyp@...lanox.com>,
	Arnd Bergmann <arnd@...db.de>
Subject: Re: mlx5e throwing RTNL_ASSERT error on vxlan_get_rx_port

Hello,

On 22.04.2016 22:02, Saeed Mahameed wrote:
> On Fri, Apr 22, 2016 at 10:30 PM, Alexander Duyck
> <alexander.duyck@...il.com> wrote:
>> From what I can tell it looks like the recent commit that changed the
>> behavior for vxlan_get_rx_port has broken the mlx5 driver as it was
>> calling vxlan_get_rx_port in mlx5e_create_netdev which didn't hold the
>> rtnl lock.  As a result it is throwing RTNL_ASSERT errors.
>>
> 
> Nice catch Alex.
> 
>> I'm not sure if anyone has already seen this or not but I thought I
>> would bring it to your attention.  Odds are this probably something
>> that needs to be fixed in the mlx5e driver and if I have time I might
>> get to it sometime in the next several days if nobody else ends up
>> addressing it.
>>
> 
> Matt will handle it, he is already preparing two fixes in mlx5 vxlan
> area, one is to address the kconfig issue Arnd reported and the other
> is to address the scheduling while atomic in mlx5e_vxlan_add ndo
> implementation which can sleep, from vxlan module it is called under
> rcu_read_lock.

Hm, I probably overlooked something during review or this change in
vxlan_get_rx_port or something came in during the time I was pushing
those changes at the same time. I just had a look and the fix shouldn't
be that hard.

Thanks,
Hannes