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 91A60C61DA4 for ; Wed, 15 Mar 2023 20:28:52 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230366AbjCOU2v (ORCPT ); Wed, 15 Mar 2023 16:28:51 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50746 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229916AbjCOU2s (ORCPT ); Wed, 15 Mar 2023 16:28:48 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 83C7559D0; Wed, 15 Mar 2023 13:28:46 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id B816AB81F15; Wed, 15 Mar 2023 20:28:44 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0EDE4C433D2; Wed, 15 Mar 2023 20:28:41 +0000 (UTC) Date: Wed, 15 Mar 2023 16:28:40 -0400 From: Steven Rostedt To: Joel Fernandes Cc: Uladzislau Rezki , Jens Axboe , LKML , RCU , "Paul E . McKenney" , Oleksiy Avramchenko , Philipp Reisner , Bryan Tan , Eric Dumazet , Bob Pearson , Ariel Levkovich , "Theodore Ts'o" , Julian Anastasov Subject: Re: [PATCH 00/13] Rename k[v]free_rcu() single argument to k[v]free_rcu_mightsleep() Message-ID: <20230315162840.106a5b4f@gandalf.local.home> In-Reply-To: References: <20230201150815.409582-1-urezki@gmail.com> <20230315151415.2534e11c@gandalf.local.home> <20230315153448.6914f85b@gandalf.local.home> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 15 Mar 2023 15:57:02 -0400 Joel Fernandes wrote: > > I was going to suggest "kvfree_rcu_might_synchronize()" but that's just > > getting ridiculous. > > No, synchronize() is incorrect. The code really can sleep for other > reasons like memory allocation. It is not that simple of an > implementation as one may imagine. mightsleep is really the correct > wording IMHO. > > > Still, I will replace that code back to a kfree() and rcu_synchonize() than > > to let that other name get in. > > I think it is too late for that for now, we already have conversions > going into the other subsystems, that means we'll have to redo all > that over again (even if it sounded like a good idea, which it is > not). > > I would rather you just did: "#define kvfree_rcu_tracing > #kvfree_rcu_mightsleep", or something like that, if it is really a > problem. ;-) > > Also you are really the first person I know of who has a problem with that name. I guess you didn't read Jens's reply. The main issue I have with this, is that "might_sleep" is just an implementation issue. It has *nothing* to do with what the call is about. It is only about freeing something with RCU. It has nothing to do with sleeping. I don't use it because it might sleep. I use it to free something. If you don't like kvfree_rcu_synchronization() then call it kvfree_rcu_headless() and note that currently it can sleep. Because in the future, if we come up with an implementation where we it doesn't sleep, then we don't need to go and rename all the users in the future. See where I have the problem with the name "might_sleep"? -- Steve