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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id A7306C4332F for ; Fri, 2 Dec 2022 23:50:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234150AbiLBXuD (ORCPT ); Fri, 2 Dec 2022 18:50:03 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51940 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229606AbiLBXuC (ORCPT ); Fri, 2 Dec 2022 18:50:02 -0500 Received: from mail-qt1-x834.google.com (mail-qt1-x834.google.com [IPv6:2607:f8b0:4864:20::834]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF32DFA44F for ; Fri, 2 Dec 2022 15:50:01 -0800 (PST) Received: by mail-qt1-x834.google.com with SMTP id l15so7411424qtv.4 for ; Fri, 02 Dec 2022 15:50:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelfernandes.org; s=google; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=eQkAr9mSx5+4OR8wvcltri5YQ2lS8vvtfycbVO8qMjw=; b=AfiGd+itfYPlAUA0pv80S+0+Twk32AeySLSZNLspwjQghf/PeNsAPMK66GWymVRMVw M8akmqKUNlbIgrS6LZeCF/awKSl862XgRH53qHLG60CmqWhPiordrKVpvfcs8Uq8flC9 NRfnf0UDalk3u1SeBDqk1bPa6wxeXNkdJsUpw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=eQkAr9mSx5+4OR8wvcltri5YQ2lS8vvtfycbVO8qMjw=; b=NLSy9hxhxspTJKVypPWJJjqu8n6MZTY1Hd1qZ42jbv5K3cquEt4Qh6I4pe5BoAdTsW hOvcpSV2heSULCg1tQRqdQb16ak3pnqICp9/tJHePpVsVx1vSDOGK2agC44SoH+jyZxR spg3ceJ34dj04TFqzdwfd728bxNwd1MlrCqWY4OTRXDSPZ+ElPiH0R9bJT3AXvpY3PkR z+Gb5wXuZkhrZr1CvS0xh3ltjm/G0D4ky8gUR9rmACcrtRgVqp9DPeUp+tVQs8H9b7HX +wh22VsSyFT6cFKh3WnhHPLBF1VGSeXjyAiIujGjWB9SyA6JqYM8nRSASonEZbq4nkII GXIw== X-Gm-Message-State: ANoB5pnbl8Py2TNrVMX0YtMTyzMVJhK8ztmusxXkiWZ+HCK3CrQ+46oP YTHj5UJFOKZ/KuqUBhmKcJbuag== X-Google-Smtp-Source: AA0mqf77fr4dtrt98HSRzD38Tz7lzrVmisOOx15QDM8oVzhBcIThqT/5W7R2jJkoaqqsJm1BNVupkw== X-Received: by 2002:ae9:ef0a:0:b0:6fc:a689:204d with SMTP id d10-20020ae9ef0a000000b006fca689204dmr8522471qkg.467.1670025000746; Fri, 02 Dec 2022 15:50:00 -0800 (PST) Received: from localhost (228.221.150.34.bc.googleusercontent.com. [34.150.221.228]) by smtp.gmail.com with ESMTPSA id s18-20020a05620a29d200b006f9ddaaf01esm6919304qkp.102.2022.12.02.15.49.59 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 02 Dec 2022 15:49:59 -0800 (PST) Date: Fri, 2 Dec 2022 23:49:59 +0000 From: Joel Fernandes To: Eric Dumazet Cc: "David S . Miller" , Jakub Kicinski , Paolo Abeni , netdev@vger.kernel.org, eric.dumazet@gmail.com, Dmitry Safonov , "Paul E . McKenney" Subject: Re: [PATCH net-next] tcp: use 2-arg optimal variant of kfree_rcu() Message-ID: References: <20221202052847.2623997-1-edumazet@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221202052847.2623997-1-edumazet@google.com> Precedence: bulk List-ID: X-Mailing-List: netdev@vger.kernel.org On Fri, Dec 02, 2022 at 05:28:47AM +0000, Eric Dumazet wrote: > kfree_rcu(1-arg) should be avoided as much as possible, > since this is only possible from sleepable contexts, > and incurr extra rcu barriers. > > I wish the 1-arg variant of kfree_rcu() would > get a distinct name, like kfree_rcu_slow() > to avoid it being abused. Hi Eric, Nice to see your patch. Paul, all, regarding Eric's concern, would the following work to warn of users? Credit to Paul/others for discussing the idea on another thread. One thing to note here is, this debugging will only be in effect on preemptible kernels, but should still help catch issues hopefully. The other idea Paul mentioned is to introduce a new dedicated API for 1-arg sleepable cases. My concern with that was that, that being effective depends on the user using the right API in the first place. I did not test it yet, but wanted to discuss a bit first. Cheers, - Joel ---8<----------------------- diff --git a/include/linux/rcutiny.h b/include/linux/rcutiny.h index 9bc025aa79a3..112d230279ea 100644 --- a/include/linux/rcutiny.h +++ b/include/linux/rcutiny.h @@ -106,6 +106,11 @@ static inline void __kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func) } // kvfree_rcu(one_arg) call. + if (IS_ENABLED(CONFIG_PREEMPT_COUNT) && preemptible() && !head) { + WARN_ONCE(1, "%s(): Please provide an rcu_head in preemptible" + " contexts to avoid long waits!\n", __func__); + } + might_sleep(); synchronize_rcu(); kvfree((void *) func); diff --git a/kernel/rcu/tree.c b/kernel/rcu/tree.c index 0ca21ac0f064..b29df1305a2e 100644 --- a/kernel/rcu/tree.c +++ b/kernel/rcu/tree.c @@ -3324,6 +3324,11 @@ void kvfree_call_rcu(struct rcu_head *head, rcu_callback_t func) * only. For other places please embed an rcu_head to * your data. */ + if (IS_ENABLED(CONFIG_PREEMPT_COUNT) && preemptible() && !head) { + WARN_ONCE(1, "%s(): Please provide an rcu_head in preemptible" + " contexts to avoid long waits!\n", __func__); + } + might_sleep(); ptr = (unsigned long *) func; }