netdev - Re: [PATCH] vxlan: remove the redundant gro_cells

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]

Date:   Fri, 15 Mar 2019 16:25:09 +0100
From:   Stefano Brivio <sbrivio@...hat.com>
To:     Zhiqiang Liu <liuzhiqiang26@...wei.com>
Cc:     <davem@...emloft.net>, <petrm@...lanox.com>, <idosch@...lanox.com>,
        <sd@...asysnail.net>, <mousuanming@...wei.com>,
        <netdev@...r.kernel.org>, Mingfangsen <mingfangsen@...wei.com>,
        "Zhoukang (A)" <zhoukang7@...wei.com>,
        "wangxiaogang (F)" <wangxiaogang3@...wei.com>,
        Eric Dumazet <eric.dumazet@...il.com>
Subject: Re: [PATCH] vxlan: remove the redundant gro_cells_destroy()
 calling.

On Fri, 15 Mar 2019 22:55:52 +0800
Zhiqiang Liu <liuzhiqiang26@...wei.com> wrote:

> > On Fri, 15 Mar 2019 18:06:45 +0800
> > Zhiqiang Liu <liuzhiqiang26@...wei.com> wrote:
> >   
> >> From: "Suanming.Mou" <mousuanming@...wei.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@...wei.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