netdev - Re: [PATCH v4 net-next 03/12] net-shapers: implement NL get operation

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: <20240826185555.3f460af4@kernel.org>
Date: Mon, 26 Aug 2024 18:55:55 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Paolo Abeni <pabeni@...hat.com>
Cc: netdev@...r.kernel.org, Jiri Pirko <jiri@...nulli.us>, Madhu Chittim
 <madhu.chittim@...el.com>, Sridhar Samudrala <sridhar.samudrala@...el.com>,
 Simon Horman <horms@...nel.org>, John Fastabend <john.fastabend@...il.com>,
 Sunil Kovvuri Goutham <sgoutham@...vell.com>, Jamal Hadi Salim
 <jhs@...atatu.com>, Donald Hunter <donald.hunter@...il.com>
Subject: Re: [PATCH v4 net-next 03/12] net-shapers: implement NL get
 operation

On Fri, 23 Aug 2024 10:52:04 +0200 Paolo Abeni wrote:
> >> + * comprising the shaper scope and a scope-specific id.
> >> + */
> >> +struct net_shaper_ops {
> >> +	/**
> >> +	 * @group: create the specified shapers scheduling group
> >> +	 *
> >> +	 * Nest the @leaves shapers identified by @leaves_handles under the
> >> +	 * @root shaper identified by @root_handle. All the shapers belong
> >> +	 * to the network device @dev. The @leaves and @leaves_handles shaper
> >> +	 * arrays size is specified by @leaves_count.
> >> +	 * Create either the @leaves and the @root shaper; or if they already
> >> +	 * exists, links them together in the desired way.
> >> +	 * @leaves scope must be NET_SHAPER_SCOPE_QUEUE.  
> > 
> > Or SCOPE_NODE, no?  
> 
> I had a few back-and-forth between the two options, enforcing only QUEUE 
> leaves or allowing even NODE.
> 
> I think the first option is general enough - can create arbitrary 
> topologies with the same amount of operations - and leads to slightly 
> simpler code, but no objections for allow both.

Ah, so we can only "grow the tree from the side of the leaves", 
so to speak? We can't create a group in the middle of the hierarchy?
I have no strong use for groups in between, maybe just mention in
a comment or cover letter.

> >> +static int net_shaper_fill_handle(struct sk_buff *msg,
> >> +				  const struct net_shaper_handle *handle,
> >> +				  u32 type, const struct genl_info *info)
> >> +{
> >> +	struct nlattr *handle_attr;
> >> +
> >> +	if (handle->scope == NET_SHAPER_SCOPE_UNSPEC)
> >> +		return 0;  
> > 
> > In what context can we try to fill handle with scope unspec?  
> 
> Uhmm... should happen only in buggy situation. What about adding adding 
> WARN_ON_ONCE() ?

That's better, at least it will express that it's not expected.

> >> +	handle_attr = nla_nest_start_noflag(msg, type);
> >> +	if (!handle_attr)
> >> +		return -EMSGSIZE;
> >> +
> >> +	if (nla_put_u32(msg, NET_SHAPER_A_SCOPE, handle->scope) ||
> >> +	    (handle->scope >= NET_SHAPER_SCOPE_QUEUE &&
> >> +	     nla_put_u32(msg, NET_SHAPER_A_ID, handle->id)))
> >> +		goto handle_nest_cancel;  
> > 
> > So netdev root has no id and no scope?  
> 
> I don't understand the question.
> 
> The root handle has scope NETDEV and id 0, the id will not printed out 
> as redundant: there is only a scope NETDEV shaper per struct net_device.

Misread, yes, no id but it does have scope. That's fine, sorry.