netdev - Re: [patch net-next 1/2] rtnetlink: allow to register ops without ops->setup set

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]

Message-ID: <20140625163108.GB2972@minipsycho.orion>
Date:	Wed, 25 Jun 2014 18:31:08 +0200
From:	Jiri Pirko <jiri@...nulli.us>
To:	"Eric W. Biederman" <ebiederm@...ssion.com>
Cc:	netdev@...r.kernel.org, davem@...emloft.net, pshelar@...ira.com,
	cwang@...pensource.com, nicolas.dichtel@...nd.com,
	david@...son.dropbear.id.au, sfeldma@...ulusnetworks.com,
	sucheta.chakraborty@...gic.com, stephen@...workplumber.org
Subject: Re: [patch net-next 1/2] rtnetlink: allow to register ops without
 ops->setup set

Wed, Jun 25, 2014 at 05:55:02PM CEST, ebiederm@...ssion.com wrote:
>Jiri Pirko <jiri@...nulli.us> writes:
>
>> So far, it is assumed that ops->setup is filled up. But there might be
>> case that ops might make sense even without ->setup. In that case,
>> forbid to newlink and dellink.
>
>This patch does not handle all cases of dellink, and so you have created
>a way to oops the kernel.  One case that is not handled is
>default_device_exit_batch.

Thanks. Missed that.

>
>Further using !setup to prevent dellink does not make any kind of
>logical sense.  Which leads to a maintenance hazard.  Aka how can we
>further update this code without running into weird corner cases.

You are right. Changed this in next patch iteration.


>
>Further you have not given a description why anyone would want to have
>something that is almost completely unlike rtnl link operations
>implemented with the rtnl link operations.


Well the main reason is that this is consistent way of telling what kind
of netdevice or slave kind this is to userspace. I do not see any reason
to do it in some other way. We just would not use rtnllinkops to its full
potential in cases like this, which is I believe ok.

I will extend the patch desc.

Thanks for review Eric.

>
>
>> Signed-off-by: Jiri Pirko <jiri@...nulli.us>
>> ---
>>  net/core/rtnetlink.c | 5 ++++-
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
>> index 1063996..84affd7 100644
>> --- a/net/core/rtnetlink.c
>> +++ b/net/core/rtnetlink.c
>> @@ -1777,7 +1777,7 @@ static int rtnl_dellink(struct sk_buff *skb, struct nlmsghdr *nlh)
>>  		return -ENODEV;
>>  
>>  	ops = dev->rtnl_link_ops;
>> -	if (!ops)
>> +	if (!ops || !ops->setup)
>>  		return -EOPNOTSUPP;
>>  
>>  	ops->dellink(dev, &list_kill);
>> @@ -2038,6 +2038,9 @@ replay:
>>  			return -EOPNOTSUPP;
>>  		}
>>  
>> +		if (!ops->setup)
>> +			return -EOPNOTSUPP;
>> +
>>  		if (!ifname[0])
>>  			snprintf(ifname, IFNAMSIZ, "%s%%d", ops->kind);
--
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