netdev - Re: [PATCH net v2] Revert "net/ncsi: change from ndo_set_mac_address to dev_set_mac

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: <0ecf17dd64e3f492087fea9e9e5213424fc1ce53.camel@gmail.com>
Date: Thu, 09 Jan 2025 00:48:07 +0300
From: Ivan Mikhaylov <fr0st61te@...il.com>
To: Paul Fertser <fercerpav@...il.com>, Jakub Kicinski <kuba@...nel.org>
Cc: davem@...emloft.net, netdev@...r.kernel.org, edumazet@...gle.com, 
	pabeni@...hat.com, andrew+netdev@...n.ch, horms@...nel.org, Potin Lai
	 <potin.lai@...ntatw.com>, Potin Lai <potin.lai.pt@...il.com>, 
	sam@...dozajonas.com
Subject: Re: [PATCH net v2] Revert "net/ncsi: change from
 ndo_set_mac_address to dev_set_mac_address"

On Wed, 2025-01-08 at 23:23 +0300, Paul Fertser wrote:
> Hello,
> 
> On Wed, Jan 08, 2025 at 11:23:46AM -0800, Jakub Kicinski wrote:
> > Looks like we're not making any progress on this one, so let's
> > go with the revert for 6.13.
> 
> But this does break userspace, the commit was there for a reason.
> 
> Potin Lai, have you tried deferring this to a work queue instead of
> reverting to the code which has always been wrong?

Jakub, thanks for letting know about revert. ndo_set_mac_address do not
notify userspace about MAC change and as Paul stated it was always been
wrong here.

And we talked about reverts in this thread -
https://lore.kernel.org/all/20231210215356.4154-1-fr0st61te@gmail.com/

Probably, incremental proper fix would be better here?

Common case is 1 NCSI interface for server, we tested on this one and
works fine for us and that's the reason why we didn't catch that
situation. Nowadays some new servers has more than one NCSI interface.
Probably we missed that is softirq context which is obviously not a
place for rtnl_lock/unlock. Is there any other solution about except
delaying dev_set_mac_address in work queue? Or any suggestions about
how to deal with that in a proper way?

Don't have any hw with >2 NCSI interface, probably need help with
testing.

Potin, can you help with checking the fix?

Thanks.