netdev - Re: [PATCH net-next 2/3] eth: platform: add a helper for loading netdev->dev

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: <16f34ede9a885a443bb7c46255ee804f@walle.cc>
Date:   Thu, 07 Oct 2021 15:42:17 +0200
From:   Michael Walle <michael@...le.cc>
To:     Jakub Kicinski <kuba@...nel.org>
Cc:     davem@...emloft.net, netdev@...r.kernel.org,
        vladimir.oltean@....com, andrew@...n.ch
Subject: Re: [PATCH net-next 2/3] eth: platform: add a helper for loading
 netdev->dev_addr

Am 2021-10-07 15:25, schrieb Jakub Kicinski:
> 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.
> 
> There is a handful of drivers which pass netdev->dev_addr as
> the destination buffer to eth_platform_get_mac_address().
> Add a helper which takes a dev pointer instead, so it can call
> an appropriate helper.
> 
> Signed-off-by: Jakub Kicinski <kuba@...nel.org>
> ---
..

> +/**
> + * platform_get_ethdev_address - Set netdev's MAC address from a given 
> device
> + * @dev:	Pointer to the device
> + * @netdev:	Pointer to netdev to write the address to
> + *
> + * Wrapper around eth_platform_get_mac_address() which writes the 
> address
> + * directly to netdev->dev_addr.
> + */
> +int platform_get_ethdev_address(struct device *dev, struct net_device 
> *netdev)
> +{
> +	u8 addr[ETH_ALEN];
> +	int ret;
> +
> +	ret = eth_platform_get_mac_address(dev, addr);

this eventually calls ether_addr_copy(), which has a note:
   Please note: dst & src must both be aligned to u16.

Is this true for this addr on the stack?

-michael