netdev - Re: [PATCH net-next 05/12] fddi: defxx,defza: use dev_addr

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