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]
Message-ID: <alpine.DEB.2.21.2110202009200.31442@angie.orcam.me.uk>
Date:   Wed, 20 Oct 2021 20:16:42 +0200 (CEST)
From:   "Maciej W. Rozycki" <macro@...am.me.uk>
To:     Jakub Kicinski <kuba@...nel.org>
cc:     davem@...emloft.net, netdev@...r.kernel.org
Subject: Re: [PATCH net-next 05/12] fddi: defxx,defza: use dev_addr_set()

On Wed, 20 Oct 2021, Jakub Kicinski wrote:

> Commit 406f42fa0d3c ("net-next: When a bond have a massive amount
> of VLANs...") introduced a rbtree for faster Ethernet address look
> up. To maintain netdev->dev_addr in this tree we need to make all
> the writes to it got through appropriate helpers.

 FDDI does not have a concept of a VLAN, so I guess this is more of a 
cosmetic nature rather than addressing an actual problem, right?

 As I noted in the other message I think this might best be abstracted,
e.g. by calling the entry point here say `fddidev_addr_set' while the 
entry point used by Ethernet devices could be `etherdev_addr_set', so that 
it is immediately obvious that we have different data link layers, even if 
the implementation of the handler would be the same for both.

 Otherwise:

Acked-by: Maciej W. Rozycki <macro@...am.me.uk>

  Maciej

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ