Re: [PATCH] vxlan: remove the redundant gro_cells_destroy() calling.

[Stefano Brivio <sbrivio@redhat.com>]

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.

-- 
Stefano