netdev - Re: RFC: Should net namespaces scale up (>10k) ?

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: <cd8045c03573a012f71a1afdcfb5d9c108b6fefa.camel@sipsolutions.net>
Date: Tue, 08 Oct 2024 20:22:38 +0200
From: Johannes Berg <johannes@...solutions.net>
To: Kuniyuki Iwashima <kuniyu@...zon.com>, alexandre.ferrieux@...il.com
Cc: alexandre.ferrieux@...nge.com, edumazet@...gle.com, horms@...nel.org, 
	netdev@...r.kernel.org, linux-wireless@...r.kernel.org
Subject: Re: RFC: Should net namespaces scale up (>10k) ?

On Tue, 2024-10-08 at 10:47 -0700, Kuniyuki Iwashima wrote:

> > 1. The "netdevice notifier" from the Wireless Extensions subsystem
> > insists on scanning the whole list regardless of the nature of the
> > change, nor wondering whether all these namespaces hold any wireless
> > interface, nor even whether the system has _any_ wireless hardware...
> > 
> >         for_each_net(net) {
> >                 while ((skb = skb_dequeue(&net->wext_nlevents)))
> >                         rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL,
> >                                     GFP_KERNEL);
> >         }
> > 
> 
> Alex forwarded this mail to me and asked about 1.
> 
> I checked 8bf862739a778, but I didn't see why wext_netdev_notifier_call()
> needs to iterate all netns.

Agree. That code is ancient, and I don't remember why, but I'd think
it's just because I was lazy then.

> diff --git a/net/wireless/wext-core.c b/net/wireless/wext-core.c
> index 838ad6541a17..d4b613fc650c 100644
> --- a/net/wireless/wext-core.c
> +++ b/net/wireless/wext-core.c
> @@ -343,17 +343,22 @@ static const int compat_event_type_size[] = {
>  
>  /* IW event code */
>  
> -void wireless_nlevent_flush(void)
> +static void wireless_nlevent_flush_net(struct net *net)
>  {
>  	struct sk_buff *skb;
> +
> +	while ((skb = skb_dequeue(&net->wext_nlevents)))
> +		rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL,
> +			    GFP_KERNEL);
> +}
> +
> +void wireless_nlevent_flush(void)
> +{
>  	struct net *net;
>  
>  	down_read(&net_rwsem);
> -	for_each_net(net) {
> -		while ((skb = skb_dequeue(&net->wext_nlevents)))
> -			rtnl_notify(skb, net, 0, RTNLGRP_LINK, NULL,
> -				    GFP_KERNEL);
> -	}
> +	for_each_net(net)
> +		wireless_nlevent_flush_net(net);
>  	up_read(&net_rwsem);
>  }
>  EXPORT_SYMBOL_GPL(wireless_nlevent_flush);

Note 1: I just posted this patch yesterday:
https://lore.kernel.org/linux-wireless/20241007214715.3dd736dc3ac0.I1388536e99c37f28a007dd753c473ad21513d9a9@changeid/

so that would conflict here, I'd think.

Note 2: the only other caller to wireless_nlevent_flush() is from
wireless_nlevent_process()/wireless_nlevent_work, and that work could
easily be made per netns since it comes along with net->wext_nlevents,
and then we don't need any global function at all. Seems this could be
implemented in wext_pernet_init()/wext_pernet_exit() pretty easily?

johannes