netdev - Re: [PATCH v2 net-next 2/3] pfcp: Convert pfcp_net_exit() to ->exit

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: <20250423064026.636c822f@kernel.org>
Date: Wed, 23 Apr 2025 06:40:26 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Kuniyuki Iwashima <kuniyu@...zon.com>
Cc: Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Simon Horman <horms@...nel.org>, Kuniyuki Iwashima
 <kuni1840@...il.com>, <netdev@...r.kernel.org>
Subject: Re: [PATCH v2 net-next 2/3] pfcp: Convert pfcp_net_exit() to
 ->exit_rtnl().

On Thu, 17 Apr 2025 17:32:33 -0700 Kuniyuki Iwashima wrote:
> -static void __net_exit pfcp_net_exit(struct net *net)
> +static void __net_exit pfcp_net_exit_rtnl(struct net *net,
> +					  struct list_head *dev_to_kill)
>  {
>  	struct pfcp_net *pn = net_generic(net, pfcp_net_id);
>  	struct pfcp_dev *pfcp, *pfcp_next;
> -	struct net_device *dev;
> -	LIST_HEAD(list);
> -
> -	rtnl_lock();
> -	for_each_netdev(net, dev)
> -		if (dev->rtnl_link_ops == &pfcp_link_ops)
> -			pfcp_dellink(dev, &list);
>  
>  	list_for_each_entry_safe(pfcp, pfcp_next, &pn->pfcp_dev_list, list)
> -		pfcp_dellink(pfcp->dev, &list);
> -
> -	unregister_netdevice_many(&list);
> -	rtnl_unlock();
> +		pfcp_dellink(pfcp->dev, dev_to_kill);

Kuniyuki, I got distracted by the fact the driver is broken but I think
this isn't right. The devices do not migrate to the local pcfp_dev_list
when their netns is changed. They always stay on the list of original
netns. Which I guess may make some sense as that's where their socket
is? So we need to scan both the pcfp_dev_list _and_ the local netdevs
that are pfcp. Am I misunderstanding something?

For gtp was the problem perhaps that we were walking multiple
netns'es? I'm my understanding is correct then 4ccacf86491 needs 
a redo :(