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 PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 7 Feb 2022 19:39:47 +0100 From: Oliver Hartkopp <socketcan@...tkopp.net> To: Eric Dumazet <edumazet@...gle.com> Cc: Eric Dumazet <eric.dumazet@...il.com>, "David S . Miller" <davem@...emloft.net>, Jakub Kicinski <kuba@...nel.org>, netdev <netdev@...r.kernel.org>, David Ahern <dsahern@...nel.org>, Marc Kleine-Budde <mkl@...gutronix.de> Subject: Re: [PATCH net-next 09/11] can: gw: switch cangw_pernet_exit() to batch mode On 07.02.22 18:54, Eric Dumazet wrote: > On Mon, Feb 7, 2022 at 9:41 AM Oliver Hartkopp <socketcan@...tkopp.net> wrote: (..) >>> -static void __net_exit cangw_pernet_exit(struct net *net) >>> +static void __net_exit cangw_pernet_exit_batch(struct list_head *net_list) >>> { >>> + struct net *net; >>> + >>> rtnl_lock(); >>> - cgw_remove_all_jobs(net); >>> + list_for_each_entry(net, net_list, exit_list) >>> + cgw_remove_all_jobs(net); >> >> Instead of removing the jobs for ONE net namespace it seems you are >> remove removing the jobs for ALL net namespaces? >> >> Looks wrong to me. > > I see nothing wrong in my patch. > > I think you have to look more closely at ops_exit_list() in > net/core/net_namespace.c Ok, thanks. Your patch just moved the list_for_each_entry() to gw.c. So there is no functional difference. Acked-by: Oliver Hartkopp <socketcan@...tkopp.net> > BTW, the sychronize_rcu() call in cgw_remove_all_jobs is definitely > bad, you should absolutely replace it by call_rcu() or kfree_rcu() Advise is welcome! The synchronize_rcu() has been introduced in fb8696ab14ad ("can: gw: synchronize rcu operations before removing gw job entry") as can_can_gw_rcv() is called under RCU protection (NET_RX softirq). That patch was a follow-up to d5f9023fa61e ("can: bcm: delay release of struct bcm_op after synchronize_rcu()") where Thadeu Lima de Souza Cascardo detected a race in the BCM code. When call_rcu() is enough to make sure we do not get a race in can_can_gw_rcv() while receiving skbs and removing filters with cgw_unregister_filter() I would be happy this rcu thing being fixed up. Best regards, Oliver
Powered by blists - more mailing lists