| Message ID | 2276c137-d5c0-bdbe-f5c7-5985ffc497ce@huawei.com |
|---|---|
| State | Superseded |
| Delegated to: | David Miller |
| Headers | show |
| Series | vxlan: remove the redundant gro_cells_destroy() calling. | expand |
On Fri, 15 Mar 2019 18:06:45 +0800 Zhiqiang Liu <liuzhiqiang26@huawei.com> wrote: > From: "Suanming.Mou" <mousuanming@huawei.com> > > With ad6c9986bcb6, GRO cells will be destroyed in vxlan_uninit. Thanks for cleaning this up. I think it would be nice if you could actually explain in the commit message why this makes the call in vxlan_destroy_tunnels() redundant. > Fixes: ad6c9986bcb6 ("vxlan: Fix GRO cells race condition between receive and link delete") I'm not sure a Fixes: tag is appropriate here (and also if this shouldn't be targeted for net-next) -- in the end, gro_cells_destroy() there would just return: if (!gcells->cells) return; > Signed-off-by: Suanming.Mou <mousuanming@huawei.com> Either way, Reviewed-by: Stefano Brivio <sbrivio@redhat.com>
> On Fri, 15 Mar 2019 18:06:45 +0800 > Zhiqiang Liu <liuzhiqiang26@huawei.com> wrote: > >> From: "Suanming.Mou" <mousuanming@huawei.com> >> >> With ad6c9986bcb6, GRO cells will be destroyed in vxlan_uninit. > > Thanks for cleaning this up. > > I think it would be nice if you could actually explain in the commit > message why this makes the call in vxlan_destroy_tunnels() redundant. > Thanks for your reply. Actually, the patch is a cleanup as you said. 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 Fortunately, gro_cells_destroy func will check whether gcells->cells is NULL, so even more than one call gro_cells_destroy would not cause the memory twice-free problem. >> Fixes: ad6c9986bcb6 ("vxlan: Fix GRO cells race condition between receive and link delete") > > I'm not sure a Fixes: tag is appropriate here (and also if this > shouldn't be targeted for net-next) -- in the end, gro_cells_destroy() > there would just return: > > if (!gcells->cells) > return; > >> Signed-off-by: Suanming.Mou <mousuanming@huawei.com> As you said, this is just a cleanup. I will remove the Fixes tag in v2 patch. I used the ./scripts/get_maintainer.pl to get the maintainers and mail-list, and the return is given as follows, [root@localhost linux]# ./scripts/get_maintainer.pl 0001-vxlan-remove-the-redundant-gro_cells_destroy-calling.patch "David S. Miller" <davem@davemloft.net> (odd fixer:NETWORKING DRIVERS,commit_signer:57/57=100%) Petr Machata <petrm@mellanox.com> (commit_signer:30/57=53%,authored:27/57=47%,added_lines:649/1160=56%,removed_lines:265/494=54%) Ido Schimmel <idosch@mellanox.com> (commit_signer:15/57=26%,removed_lines:30/494=6%) Roopa Prabhu <roopa@cumulusnetworks.com> (commit_signer:11/57=19%,authored:9/57=16%,added_lines:364/1160=31%,removed_lines:156/494=32%) Sabrina Dubroca <sd@queasysnail.net> (commit_signer:6/57=11%) Stefano Brivio <sbrivio@redhat.com> (authored:5/57=9%,added_lines:63/1160=5%) netdev@vger.kernel.org (open list:NETWORKING DRIVERS) linux-kernel@vger.kernel.org (open list) > > Either way, > > Reviewed-by: Stefano Brivio <sbrivio@redhat.com> >
On 03/15/2019 03:06 AM, Zhiqiang Liu wrote: > From: "Suanming.Mou" <mousuanming@huawei.com> > > With ad6c9986bcb6, GRO cells will be destroyed in vxlan_uninit. > > Fixes: ad6c9986bcb6 ("vxlan: Fix GRO cells race condition between receive and link delete") > This is a net-next candidate . The Fixes: tag is not needed, the cited commit added no bug.
On Fri, 15 Mar 2019 22:55:52 +0800 Zhiqiang Liu <liuzhiqiang26@huawei.com> wrote: > > On Fri, 15 Mar 2019 18:06:45 +0800 > > Zhiqiang Liu <liuzhiqiang26@huawei.com> wrote: > > > >> From: "Suanming.Mou" <mousuanming@huawei.com> > >> > >> With ad6c9986bcb6, GRO cells will be destroyed in vxlan_uninit. > > > > Thanks for cleaning this up. > > > > I think it would be nice if you could actually explain in the commit > > message why this makes the call in vxlan_destroy_tunnels() redundant. > > > Thanks for your reply. Actually, the patch is a cleanup as you said. > 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 Yes, I think this is exactly what you should add in the commit message of v2. > Fortunately, gro_cells_destroy func will check whether gcells->cells is NULL, so even more than > one call gro_cells_destroy would not cause the memory twice-free problem. > > >> Fixes: ad6c9986bcb6 ("vxlan: Fix GRO cells race condition between receive and link delete") > > > > I'm not sure a Fixes: tag is appropriate here (and also if this > > shouldn't be targeted for net-next) -- in the end, gro_cells_destroy() > > there would just return: > > > > if (!gcells->cells) > > return; > > > >> Signed-off-by: Suanming.Mou <mousuanming@huawei.com> > > As you said, this is just a cleanup. I will remove the Fixes tag in v2 patch. > I used the ./scripts/get_maintainer.pl to get the maintainers and mail-list, and the return is > given as follows, > > [...] That's correct, you sent the patch to the right addresses. But there are two trees for networking, net and net-next. See: "Q: How do I indicate which tree (net vs. net-next) my patch should be in?" in Documentation/networking/netdev-FAQ.rst (perhaps you should also read the whole thing while at it). Mind that net-next is currently closed, so you'll have to wait a bit.
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c index 077f1b9f2761..d76dfed8d9bb 100644 --- a/drivers/net/vxlan.c +++ b/drivers/net/vxlan.c @@ -4335,10 +4335,8 @@ static void vxlan_destroy_tunnels(struct net *net, struct list_head *head) /* If vxlan->dev is in the same netns, it has already been added * to the list by the previous loop. */ - if (!net_eq(dev_net(vxlan->dev), net)) { - gro_cells_destroy(&vxlan->gro_cells); + if (!net_eq(dev_net(vxlan->dev), net)) unregister_netdevice_queue(vxlan->dev, head); - } } for (h = 0; h < PORT_HASH_SIZE; ++h)