netdev - Re: [patch net-next 1/7] rtnl: use dev_set_mac_address() instead of plain ndo

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]

Date:	Tue, 1 Jan 2013 20:00:23 +0100
From:	Jiri Pirko <jiri@...nulli.us>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, edumazet@...gle.com,
	bhutchings@...arflare.com, sassmann@...hat.com, kaber@...sh.net,
	richard@....at
Subject: Re: [patch net-next 1/7] rtnl: use dev_set_mac_address() instead of
 plain ndo_

Tue, Jan 01, 2013 at 07:33:06PM CET, shemminger@...tta.com wrote:
>On Tue,  1 Jan 2013 14:30:13 +0100
>Jiri Pirko <jiri@...nulli.us> wrote:
>
>> Benefit from existence of dev_set_mac_address() and remove duplicate
>> code.
>> 
>> Signed-off-by: Jiri Pirko <jiri@...nulli.us>
>> ---
>>  net/core/rtnetlink.c | 20 ++------------------
>>  1 file changed, 2 insertions(+), 18 deletions(-)
>> 
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index 2ef7a56..78d05a9 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -1310,7 +1310,6 @@ static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
>>  		      struct nlattr **tb, char *ifname, int modified)
>>  {
>>  	const struct net_device_ops *ops = dev->netdev_ops;
>> -	int send_addr_notify = 0;
>>  	int err;
>>  
>>  	if (tb[IFLA_NET_NS_PID] || tb[IFLA_NET_NS_FD]) {
>> @@ -1363,16 +1362,6 @@ static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
>>  		struct sockaddr *sa;
>>  		int len;
>>  
>> -		if (!ops->ndo_set_mac_address) {
>> -			err = -EOPNOTSUPP;
>> -			goto errout;
>> -		}
>> -
>> -		if (!netif_device_present(dev)) {
>> -			err = -ENODEV;
>> -			goto errout;
>> -		}
>> -
>>  		len = sizeof(sa_family_t) + dev->addr_len;
>>  		sa = kmalloc(len, GFP_KERNEL);
>>  		if (!sa) {
>> @@ -1382,13 +1371,11 @@ static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
>>  		sa->sa_family = dev->type;
>>  		memcpy(sa->sa_data, nla_data(tb[IFLA_ADDRESS]),
>>  		       dev->addr_len);
>> -		err = ops->ndo_set_mac_address(dev, sa);
>> +		err = dev_set_mac_address(dev, sa);
>>  		kfree(sa);
>>  		if (err)
>>  			goto errout;
>> -		send_addr_notify = 1;
>>  		modified = 1;
>> -		add_device_randomness(dev->dev_addr, dev->addr_len);
>>  	}
>>  
>>  	if (tb[IFLA_MTU]) {
>> @@ -1425,7 +1412,7 @@ static int do_setlink(struct net_device *dev, struct ifinfomsg *ifm,
>>  
>>  	if (tb[IFLA_BROADCAST]) {
>>  		nla_memcpy(dev->broadcast, tb[IFLA_BROADCAST], dev->addr_len);
>> -		send_addr_notify = 1;
>> +		call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
>>  	}
>>  
>>  	if (ifm->ifi_flags || ifm->ifi_change) {
>> @@ -1546,9 +1533,6 @@ errout:
>>  		net_warn_ratelimited("A link change request failed with some changes committed already. Interface %s may have been left with an inconsistent configuration, please check.\n",
>>  				     dev->name);
>>  
>> -	if (send_addr_notify)
>> -		call_netdevice_notifiers(NETDEV_CHANGEADDR, dev);
>> -
>>  	return err;
>>  }
>>  
>
>This will cause call_netdevice_notifiers to be called twice if both IFLA_BROADCAST and IFLA_ADDRESS
>are changed in one request. Not sure if that would break anything?

Yep, I'm aware of this. I strongly believe all both notifier handlers
should be prepared for this (and looking at their code I believe they
are).

Userspace application monitoring rtnl events also cannot depend on fact
that IFLA_BROADCAST and IFLA_ADDRESS changes come in one message (even
now).

So I'm quite sure this wouldn't break anything.

Thanks

Jiri
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html