Received: by 2002:a05:6358:d09b:b0:dc:cd0c:909e with SMTP id jc27csp2838282rwb; Thu, 17 Nov 2022 17:20:17 -0800 (PST) X-Google-Smtp-Source: AA0mqf6g2rtI4RoTtTF0tnqLS6AdyZNtzDk6OWC52lGeGXHxSYTrPHpBFwn3DP++g8eM2zPM9Nu6 X-Received: by 2002:a17:902:d58d:b0:186:e568:3442 with SMTP id k13-20020a170902d58d00b00186e5683442mr5220512plh.56.1668734417205; Thu, 17 Nov 2022 17:20:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1668734417; cv=none; d=google.com; s=arc-20160816; b=kAQMBB606pQ4YYC5qoAZOwVcTuzu8DU5oULFhCZ1CtC87Mp1PxzHin1tx1sJVlBQ9y M0TmI3SYGgjXN0rzu7r7GlcCaGbeEyuzJVEMfGctllq1rapUfN5wOJM3MaxQIMGA3wP4 ccx1M7WED98nyxBfSTJ6uSkbFXANtT3wuR0epV9MlaNTu69CQdMEif+xi16ZJKvyVnnf JB+C8y/dYdOgUJORCQI8rBkNJVsyQwxDBtfd8BJ5NiOlQZJzp2wcKSIYz/BKeT6PCPZy CIs6yf9o/LXhJiLxAOQLrChphUfB2+sEd3jMWVzCqro/ythLxkVTVShILn0lMxiLmoGj J1rg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=1nEQgHnJ3mToQ4Y8AU47leGp2bx85OsCS3Yng1ByM5g=; b=Eps+D7YJiVENP3ZJnG/VMrEXVxGaFSlc3LqkvLPqczWkHqZ4mXkcCvi74MdeZ4slhL 18pk5E0phMkoTlfG7J4GDxF8dQ7qVedt7WxOm0woyMeLvyJnPmROH5zXHhrU90bjy18N rovDzk47sKAOviAyJAbqvXxTU14QChqyj2uio9y1zBYylX0Fg3KKw0my8F/aQL2+ZH8z gYjySBzqhrEPNUCrferzoOoqCuWw6/c/QWgxs07/i5OnA3i7dLXzLBLgoh1+gM004+f5 WQ4t6qZgjD4cf4BHviPNEI+YIZzJsmpvGOezd3iv1IAxTwCSmgFSa77cuLBAQwM9DJyQ niCg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=jAiUM6n8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id pf11-20020a17090b1d8b00b002186dc355c2si2535871pjb.31.2022.11.17.17.20.04; Thu, 17 Nov 2022 17:20:17 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20210112 header.b=jAiUM6n8; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S240898AbiKRBN3 (ORCPT + 91 others); Thu, 17 Nov 2022 20:13:29 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:33504 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S240681AbiKRBMt (ORCPT ); Thu, 17 Nov 2022 20:12:49 -0500 Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE60787545 for ; Thu, 17 Nov 2022 17:12:44 -0800 (PST) Received: by mail-io1-xd29.google.com with SMTP id p184so2783030iof.11 for ; Thu, 17 Nov 2022 17:12:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=1nEQgHnJ3mToQ4Y8AU47leGp2bx85OsCS3Yng1ByM5g=; b=jAiUM6n8fPzCk4etsLh5vHbzmAphcNVgk2NYTsSycCua2b0xBeQb7Cz/19byCflgsy X5AXgnMMBgg108CFB6nt6M2AzlTkf5g84Pq8nlXb8twtab7av3lSIlSowzqG2CH6CSNB MILL514zNmYNHE22FYO4GTdBsfD3SvqxuJplhzHnBU4qzpScYjksDrF9eX1+YIevib1F tiDUZaJygCJ3DGCcUm4hYlCBH81UZn/3Mv0fKWV1pBJqaifilkaG3tIAk2yZ7PPzjDw3 SGfdFXFMKhkL0MlH25j/NumiiZ05+lZLrR3lzxoVZCKt/ueCK4lAnnpS8VDp9NpTRKWf 8Jyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=1nEQgHnJ3mToQ4Y8AU47leGp2bx85OsCS3Yng1ByM5g=; b=ZrOHtdxT39jz+aBjIHf8pjmuHWkz29r96kqa9HlWiizQPbN0HsF3cp+ILd15OuPOBh hYgyRbgeRpikr8xCNBkyKZ3I4Gra46vvi/eMpA62P+JY/YiS6SO5OnTXNLAscgKGqyxo kgfnwSOAJtcnm1O3/2LhZmLl1FwySiPIxA3xm+0ahDaTOKfJgdoW7duDmJD833sF4KrB UFv4Sdw7l/1LHjguK8CE7TpGc1ylII05MlL2GbsEaqFWOcT3wvBlDbSfbMrasQb+ITsM eUkmTr/E6B7oMCTlf9PJ54MoJLxURno8k0XdSQn0vJq2gUe5DppwRQ94Y70xDY+/0YoK jf+w== X-Gm-Message-State: ANoB5pmLUPc9QgfoXr8jCwK5wElApuAEFsXl5Upl68wQgfbNKv1K8AF0 4XgjUOfHJTB28XdMqjNg+NNrnF9zdOjLHjYtk76xgQ== X-Received: by 2002:a5d:8f84:0:b0:6d9:56fc:ef25 with SMTP id l4-20020a5d8f84000000b006d956fcef25mr2517540iol.56.1668733963791; Thu, 17 Nov 2022 17:12:43 -0800 (PST) MIME-Version: 1.0 References: <20221117031551.1142289-1-joel@joelfernandes.org> <20221117031551.1142289-2-joel@joelfernandes.org> In-Reply-To: From: Eric Dumazet Date: Thu, 17 Nov 2022 17:12:32 -0800 Message-ID: Subject: Re: [PATCH rcu/dev 2/3] net: Use call_rcu_flush() for in_dev_rcu_put To: Joel Fernandes Cc: linux-kernel@vger.kernel.org, Cong Wang , David Ahern , "David S. Miller" , Hideaki YOSHIFUJI , Jakub Kicinski , Jamal Hadi Salim , Jiri Pirko , netdev@vger.kernel.org, Paolo Abeni , rcu@vger.kernel.org, rostedt@goodmis.org, paulmck@kernel.org, fweisbec@gmail.com Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-17.6 required=5.0 tests=BAYES_00,DKIMWL_WL_MED, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF, ENV_AND_HDR_SPF_MATCH,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS, USER_IN_DEF_DKIM_WL,USER_IN_DEF_SPF_WL autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 17, 2022 at 4:52 PM Joel Fernandes wrote: > > Hi Eric, > > On Thu, Nov 17, 2022 at 01:58:18PM -0800, Eric Dumazet wrote: > > On Wed, Nov 16, 2022 at 7:16 PM Joel Fernandes (Google) > > wrote: > > > > > > In a networking test on ChromeOS, we find that using the new CONFIG_RCU_LAZY > > > causes a networking test to fail in the teardown phase. > > > > > > The failure happens during: ip netns del > > > > > > Using ftrace, I found the callbacks it was queuing which this series fixes. Use > > > call_rcu_flush() to revert to the old behavior. With that, the test passes. > > > > > > Signed-off-by: Joel Fernandes (Google) > > > --- > > > net/ipv4/devinet.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c > > > index e8b9a9202fec..98b20f333e00 100644 > > > --- a/net/ipv4/devinet.c > > > +++ b/net/ipv4/devinet.c > > > @@ -328,7 +328,7 @@ static void inetdev_destroy(struct in_device *in_dev) > > > neigh_parms_release(&arp_tbl, in_dev->arp_parms); > > > arp_ifdown(dev); > > > > > > - call_rcu(&in_dev->rcu_head, in_dev_rcu_put); > > > + call_rcu_flush(&in_dev->rcu_head, in_dev_rcu_put); > > > } > > > > For this one, I suspect the issue is about device refcount lingering ? > > > > I think we should release refcounts earlier (and only delegate the > > freeing part after RCU grace period, which can be 'lazy' just fine) > > > > Something like: > > The below diff where you reduce refcount before RCU grace period, also makes the > test pass. > > If you are Ok with it, I can roll it into a patch with your Author tag and my > Tested-by. Let me know what you prefer? > > Also, looking through the patch, I don't see any issue. One thing is > netdev_put() now happens before a grace period, instead of after. But I don't > think that's an issue. Normally the early netdev_put() is fine, because these netdev are already fully RCU protected. Sure, feel free to take this patch as is, thanks.