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: <53732489.3070204@mellanox.com>
Date:	Wed, 14 May 2014 11:08:41 +0300
From:	Or Gerlitz <ogerlitz@...lanox.com>
To:	Veaceslav Falico <vfalico@...il.com>,
	Jay Vosburgh <jay.vosburgh@...onical.com>
CC:	Or Gerlitz <or.gerlitz@...il.com>, Jiri Pirko <jiri@...nulli.us>,
	"Eyal Perry" <eyalpe@...lanox.com>,
	netdev <netdev@...r.kernel.org>,
	Noa Osherovich <noaos@...lanox.com>
Subject: Re: bonding directly changes underlying device address

On 14/05/2014 11:01, Veaceslav Falico wrote:
>
> 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.

Avoid touching the slave device address directly and acting through 
dev_set_mac_address() sounds good to me.

Still, FWIW && just to make sure we see the whole picture, we noted that 
the practiceof manually touching the slave device address is done in 
another TLB code locationbesides alb_set_slave_mac_addr(), namely in 
alb_set_mac_address().

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

Interesting, so if Jay is OK with this design, any chance one of you can 
come up
with the proper patch to make that happen?

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