netdev - Re: [PATCH net-next v2 1/3] net: bridge: add support for user-controlled bool options

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: <bc90dc53-b4fc-3725-7141-556e62f027f8@cumulusnetworks.com>
Date:   Sun, 25 Nov 2018 10:12:45 +0200
From:   Nikolay Aleksandrov <nikolay@...ulusnetworks.com>
To:     Andrew Lunn <andrew@...n.ch>
Cc:     netdev@...r.kernel.org, roopa@...ulusnetworks.com,
        davem@...emloft.net, bridge@...ts.linux-foundation.org
Subject: Re: [PATCH net-next v2 1/3] net: bridge: add support for
 user-controlled bool options

On 24/11/2018 18:46, nikolay@...ulusnetworks.com wrote:
> On 24 November 2018 18:25:41 EET, Andrew Lunn <andrew@...n.ch> wrote:
>> On Sat, Nov 24, 2018 at 06:18:33PM +0200, nikolay@...ulusnetworks.com
>> wrote:
>>> On 24 November 2018 18:10:41 EET, Andrew Lunn <andrew@...n.ch> wrote:
>>>>> +int br_boolopt_toggle(struct net_bridge *br, enum br_boolopt_id
>> opt,
>>>> bool on,
>>>>> +		      struct netlink_ext_ack *extack)
>>>>> +{
>>>>> +	switch (opt) {
>>>>> +	default:
>>>>> +		/* shouldn't be called with unsupported options */
>>>>> +		WARN_ON(1);
>>>>> +		break;
>>>>
>>>> So you return 0 here, meaning the br_debug() lower down will not
>>>> happen. Maybe return -EOPNOTSUPP?
>>>>
>>>
>>> No, the idea here is that some option in the future might return an
>> error. 
>>> This function cannot be called with unsupported option thus the warn.
>>
>>
>> O.K, i was trying to make it easier to see which option caused it to
>> happen.
>>
>>>>> +	}
>>>>> +
>>>>> +	return 0;
>>>>> +}
>>>>> +
>>>>
>>>>> +int br_boolopt_multi_toggle(struct net_bridge *br,
>>>>> +			    struct br_boolopt_multi *bm,
>>>>> +			    struct netlink_ext_ack *extack)
>>>>> +{
>>>>> +	unsigned long bitmap = bm->optmask;
>>>>> +	int err = 0;
>>>>> +	int opt_id;
>>>>> +
>>>>> +	for_each_set_bit(opt_id, &bitmap, BR_BOOLOPT_MAX) {
>>>>> +		bool on = !!(bm->optval & BIT(opt_id));
>>>>> +
>>>>> +		err = br_boolopt_toggle(br, opt_id, on, extack);
>>>>> +		if (err) {
>>>>> +			br_debug(br, "boolopt multi-toggle error: option: %d current:
>> %d
>>>> new: %d error: %d\n",
>>>>> +				 opt_id, br_boolopt_get(br, opt_id), on, err);
>>>>> +			break;
>>>>> +		}
>>>>> +	}
>>>>
>>>> Does the semantics of extack allow you to return something even when
>>>> there is no error? If there are bits > BR_BOOLOPT_MAX you could
>> return
>>>> 0, but also add a warning in extack that some bits where not
>> supported
>>>> by this kernel.
>>>
>>> If we return 0 there's no reason to check extack. 
>>
>> Well, the caller can check to see if extack is present, even on
>> success. This is extack, not extnack after all...
>>
> 
> Evenif it's possible to return it without an error (I need to confirm that), the real problem is extack doesn't support
> format strings, i. e. we can't say which bit is missing which makes it useless in this case IMO. 
> 

One more thing I forgot to mention is the case with newer iproute2 and older kernel without
these patches, then the whole boolopt option will be ignored without setting extact which
makes it inconsistent if user-space would rely on that to check if options were set.
I think the best way to go if one wants to check for support is to dump the boolopts
if they're present, then optmask could be used to see what will be set (or was set).
That would be reliable in all cases.


>> 	 Andrew
>