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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Mon, 20 Mar 2017 23:20:34 -0700
From:   PJ Waskiewicz <pjwaskiewicz@...il.com>
To:     Govindarajulu Varadarajan <gvaradar@...co.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, Mar 20, 2017 at 6:49 PM, Govindarajulu Varadarajan
<gvaradar@...co.com> wrote:
> 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()")

The fix looks like it went in after 4.9 was tagged and released.  4.9
was tagged 12/11/2016, and 948b337e62ca9 was committed 1/8/2017.  That
would explain why I didn't see it in 4.9.

That being said, looks like 4.10 does work as expected without my
patch, so I'm fine carrying the patch internally to our 4.9 tree.  I'm
not sure it's worth sending either this patch or the netdev-level
patch to -stable though, it's a small issue that is already fixed
upstream.

Consider this patch rescinded.

Cheers,
-PJ

Powered by blists - more mailing lists