From: Eric Dumazet <eric.dumazet@gmail.com>
To: Stefano Brivio <sbrivio@redhat.com>,
Eric Dumazet <eric.dumazet@gmail.com>
Cc: David Miller <davem@davemloft.net>,
liuzhiqiang26@huawei.com, petrm@mellanox.com,
idosch@mellanox.com, sd@queasysnail.net, mousuanming@huawei.com,
netdev@vger.kernel.org, mingfangsen@huawei.com,
zhoukang7@huawei.com, wangxiaogang3@huawei.com
Subject: Re: [PATCH v2] vxlan: remove the redundant gro_cells_destroy() calling.
Date: Fri, 15 Mar 2019 14:26:10 -0700 [thread overview]
Message-ID: <1b09614f-e500-f59b-5f1e-f896c3fd39ac@gmail.com> (raw)
In-Reply-To: <20190315220841.078e15b7@elisabeth>
On 03/15/2019 02:08 PM, Stefano Brivio wrote:
> On Fri, 15 Mar 2019 11:56:01 -0700
> Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
>> On 03/15/2019 11:02 AM, David Miller wrote:
>>> From: Eric Dumazet <eric.dumazet@gmail.com>
>>> Date: Fri, 15 Mar 2019 09:06:25 -0700
>>>
>>>>
>>>>
>>>> On 03/15/2019 08:28 AM, Stefano Brivio wrote:
>>>>> On Fri, 15 Mar 2019 23:18:52 +0800
>>>>> Zhiqiang Liu <liuzhiqiang26@huawei.com> wrote:
>>>>>
>>>>>> In vxlan_destroy_tunnels func, unregister_netdevice_queue is called after
>>>>>> gro_cells_destroy func. However, in unregister_netdevice_queue func, the
>>>>>> gro_cells_destroy func will also call the gro_cells_destroy func as the
>>>>>> following routine:
>>>>>> unregister_netdevice_many() -> rollback_registered_many()
>>>>>> -> ndo_uninit() -> gro_cells_destroy()
>>>>>>
>>>>>> Signed-off-by: Suanming.Mou <mousuanming@huawei.com>
>>>>>> Reviewed-by: Zhiqiang Liu <liuzhiqiang26@huawei.com>
>>>>>> Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
>>>>>
>>>>> NACK, please read my and Eric's comments to v1 -- giving me more than 23
>>>>> minutes to answer would have been a nice touch as well :)
>>>>>
>>>>
>>>> Sorry for the confusion, I forgot to add the question marks to my sentences.
>>>>
>>>> In fact, this is a bug fix, that we missed in the previous fix.
>>>>
>>>> Technically the bug is older.
>>>
>>> Please elaborate.
>>>
>>
>> Commit ad6c9986bcb62
>> ("vxlan: Fix GRO cells race condition between receive and link delete")
>>
>> fixed a race condition for the typical case a vxlan device is dismantled from the
>> current netns.
>>
>> But if a netns is dismantled, we call vxlan_destroy_tunnels()
>> to schedule a unregister_netdevice_queue() of all the vxlan tunnels
>> that are related to this netns.
>
> Won't that happen via ops_exit_list() only after synchronize_rcu() is
> called by cleanup_net(), though? Is there another path I missed?
Just look at vxlan_destroy_tunnels().
The call to gro_cells_destroy(&vxlan->gro_cells);
is done _before_
unregister_netdevice_queue(vxlan->dev, head);
So packets can still fly, the RCU grace period has not yet started.
next prev parent reply other threads:[~2019-03-15 21:26 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-03-15 10:06 [PATCH] vxlan: remove the redundant gro_cells_destroy() calling Zhiqiang Liu
2019-03-15 11:54 ` Stefano Brivio
2019-03-15 14:55 ` Zhiqiang Liu
2019-03-15 15:25 ` Stefano Brivio
2019-03-15 14:58 ` Eric Dumazet
2019-03-15 15:18 ` [PATCH v2] " Zhiqiang Liu
2019-03-15 15:28 ` Stefano Brivio
2019-03-15 16:06 ` Eric Dumazet
2019-03-15 18:02 ` David Miller
2019-03-15 18:56 ` Eric Dumazet
2019-03-15 21:08 ` Stefano Brivio
2019-03-15 21:26 ` Eric Dumazet [this message]
2019-03-15 22:04 ` Stefano Brivio
2019-03-16 5:24 ` Zhiqiang Liu
2019-03-16 5:45 ` Stefano Brivio
2019-03-16 6:27 ` Zhiqiang Liu
2019-03-16 2:33 ` Zhiqiang Liu
2019-03-16 9:02 ` [PATCH net v3] vxlan: Don't call gro_cells_destroy() before device is unregistered Zhiqiang Liu
2019-03-19 0:08 ` David Miller
2019-03-15 18:02 ` [PATCH v2] vxlan: remove the redundant gro_cells_destroy() calling David Miller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1b09614f-e500-f59b-5f1e-f896c3fd39ac@gmail.com \
--to=eric.dumazet@gmail.com \
--cc=davem@davemloft.net \
--cc=idosch@mellanox.com \
--cc=liuzhiqiang26@huawei.com \
--cc=mingfangsen@huawei.com \
--cc=mousuanming@huawei.com \
--cc=netdev@vger.kernel.org \
--cc=petrm@mellanox.com \
--cc=sbrivio@redhat.com \
--cc=sd@queasysnail.net \
--cc=wangxiaogang3@huawei.com \
--cc=zhoukang7@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).