From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 5A8FCC43381 for ; Sat, 16 Mar 2019 05:46:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 2BDAB218FC for ; Sat, 16 Mar 2019 05:46:42 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726004AbfCPFqk (ORCPT ); Sat, 16 Mar 2019 01:46:40 -0400 Received: from mx1.redhat.com ([209.132.183.28]:61869 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725908AbfCPFqk (ORCPT ); Sat, 16 Mar 2019 01:46:40 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 3899F3DD99; Sat, 16 Mar 2019 05:46:40 +0000 (UTC) Received: from elisabeth (ovpn-200-27.brq.redhat.com [10.40.200.27]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 2EC4A17A77; Sat, 16 Mar 2019 05:46:01 +0000 (UTC) Date: Sat, 16 Mar 2019 06:45:07 +0100 From: Stefano Brivio To: Zhiqiang Liu Cc: Eric Dumazet , David Miller , , , , , , , , Subject: Re: [PATCH v2] vxlan: remove the redundant gro_cells_destroy() calling. Message-ID: <20190316064507.10373066@elisabeth> In-Reply-To: <308992f9-5c45-ea0c-7265-82c6976be45f@huawei.com> References: <20190315162824.732b18ac@elisabeth> <005ad387-8d51-561e-a5b9-8e851e03d5e9@gmail.com> <20190315.110249.648596993203657814.davem@davemloft.net> <20190315220841.078e15b7@elisabeth> <1b09614f-e500-f59b-5f1e-f896c3fd39ac@gmail.com> <20190315230457.094e2939@elisabeth> <308992f9-5c45-ea0c-7265-82c6976be45f@huawei.com> Organization: Red Hat MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.29]); Sat, 16 Mar 2019 05:46:40 +0000 (UTC) Sender: netdev-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Sat, 16 Mar 2019 13:24:39 +0800 Zhiqiang Liu wrote: > I have updated the commit message as suggested by Eric. Even though I have read > Documentation/networking/netdev-FAQ.rst as you mentioned. I am now still a little > confused about the subject-prefix of v3 (net or net-next). It's "net": this is a (likely critical) fix. > And David Miller saied the net-next tree is CLOSED. Right, but this is not for net-next anymore, given what Eric found. > Could you help me check whether the following v3 patch is ok? > > > Subject: [PATCH net v3] vxlan: remove the redundant gro_cells_destroy() calling. This one. And it's not just redundant, so maybe something like: "[PATCH net v3] vxlan: Don't call gro_cells_destroy() before device is unregistered" > OR > Subject: [PATCH net-next v3] vxlan: remove the redundant gro_cells_destroy() calling. > > 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, > vxlan_destroy_tunnels() is called to schedule a unregister_netdevice_queue() > of all the vxlan tunnels that are related to this netns. > > In vxlan_destroy_tunnels(), gro_cells_destroy() is called and finished before > unregister_netdevice_queue(). This means that the gro_cells_destroy() call is > done too soon, for the same reasons explained in above commit. > > So we need to fully respect the RCU rules, and thus must remove the > gro_cells_destroy() call or risk use after-free. > > Fixes: 58ce31cca1ff ("vxlan: GRO support at tunnel layer") > Signed-off-by: Suanming.Mou > Suggested-by: Eric Dumazet > Reviewed-by: Stefano Brivio > Reviewed-by: Zhiqiang Liu > --- > V1->V2: This will actually be v3. > - update the commit message suggeted by Eric Dumazet > - update Fixes: tag > > drivers/net/vxlan.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > 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) Looks good to me, you can keep my Reviewed-by: tag for v3. Thanks! -- Stefano