netdev - Re: [PATCH] enic: Store permanent MAC address during probe()

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: <alpine.LNX.2.20.1703201835570.17033@cisco>
Date:   Mon, 20 Mar 2017 18:49:21 -0700
From:   Govindarajulu Varadarajan <gvaradar@...co.com>
To:     PJ Waskiewicz <pjwaskiewicz@...il.com>
CC:     <netdev@...r.kernel.org>, Christian Benvenuti <benve@...co.com>,
        Govindarajulu Varadarajan <_govind@....com>,
        Neel Patel <neepatel@...co.com>
Subject: Re: [PATCH] enic: Store permanent MAC address during probe()

On Mon, 20 Mar 2017, PJ Waskiewicz wrote:

> On Mon, Mar 20, 2017 at 5:33 PM, Govindarajulu Varadarajan
> <gvaradar@...co.com> wrote:
>> On Mon, 20 Mar 2017, PJ Waskiewicz wrote:
>>
>>> From: PJ Waskiewicz <pjwaskiewicz@...il.com>
>>>
>>> The permanent MAC address is useful to store for things like ethtool,
>>> and when bonding with modes such as active/passive or LACP.
>>
>> Is this patch fixing an issue with bonding drive on enic?
>
> We noticed that running ethtool -P <eth> on an enic, even on 4.9,
> returned nothing.  This has fallout when using bonding, where LACP or
> Active/Passive overrides the LAA on one of the slaves, one can't
> figure out what the physical MAC address is of each slave.  So not a
> problem with bonding directly, it's more secondary as a result of the
> driver not reporting the actual permanent address.
>
>>
>>> This follows the model of other Ethernet drivers, such as ixgbe.
>>>
>>
>> While other drivers set netdev->perm_addr, doesn't this actually come free
>> in
>> register_netdevice().
>
> I thought it did as well, but in 4.9 when we tested it wasn't working.
> Hence the patch.  :-)
>

Can you try with net-next? In my setup I do not see the issue on net-next and on
4.9 kernel. The issue for all drivers was fixed in
948b337e62ca9 ("net: init perm_addr in register_netdevice()")