netdev - Re: bonding directly changes underlying device address

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: <20140514080114.GA30960@mikrodark.usersys.redhat.com>
Date:	Wed, 14 May 2014 10:01:14 +0200
From:	Veaceslav Falico <vfalico@...il.com>
To:	Or Gerlitz <or.gerlitz@...il.com>
Cc:	Jay Vosburgh <jay.vosburgh@...onical.com>,
	Jiri Pirko <jiri@...nulli.us>,
	Or Gerlitz <ogerlitz@...lanox.com>,
	Eyal Perry <eyalpe@...lanox.com>,
	netdev <netdev@...r.kernel.org>,
	Noa Osherovich <noaos@...lanox.com>
Subject: Re: bonding directly changes underlying device address

On Tue, May 13, 2014 at 08:38:01PM +0300, Or Gerlitz wrote:
>On Tue, May 13, 2014 at 7:30 PM, Jay Vosburgh
><jay.vosburgh@...onical.com> wrote:
>>>Tue, May 13, 2014 at 01:06:56PM CEST, ogerlitz@...lanox.com wrote:
>
>[...]
>
>>>>I suspect this can lead to funny (or actually sad) bugs in networking
>>>>drivers, can we avoid that?
>
>>         Changing this would also remove support for the tlb mode from
>> any device that cannot change their MAC while open.  I don't know how
>> many devices that is (it's probably a small number nowadays), but if
>> it's not zero then an assessment on losing that support has to be made.
>
>Focusing on the last part of your reply, are you OK with a patch that
>branches on whether that device supports ndo_set_mac_address and if
>this is the case we will call dev_set_mac_address, else do the current
>practice of setting dev_addr directly?

I'd actually just drop support for non-ndo_set_mac_address NICs, as it'll
unify the RLB and TLB logic, and anyways dev_set_mac_address() is used in
SIOCSIFHWADDR and rtnl ops, and thus, if the NIC doesn't support it, it
can't change its mac address at all, and using it in *LB modes makes little
sense.

Other way of doing this would be to just move the dev_addr to the slave
struct, instead of using the net_device's dev_addr, cause in tlb we don't
usually need to set the NIC mac address (except when there's mac filtering,
I guess), but only need to set the packet's source mac. This way we'll omit
quite costy mac address setting (as, on some NICs, it resets the whole NIC
and takes seconds), still maintain compatibility with older NICs and won't
mess with NICs ->dev_addr.

Anyway, I'll let Jay decide.

>
>Or.
--
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