netdev - Re: [PATCH net-next 09/11] can: gw: switch cangw_pernet

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: <70900ebc-876d-cbb3-a048-9104e2e96420@hartkopp.net>
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