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 E4120C7618A for ; Wed, 15 Mar 2023 21:14:45 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230106AbjCOVOo (ORCPT ); Wed, 15 Mar 2023 17:14:44 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:57964 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232400AbjCOVOh (ORCPT ); Wed, 15 Mar 2023 17:14:37 -0400 Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C21A65BDA2; Wed, 15 Mar 2023 14:14:06 -0700 (PDT) Received: by mail-ed1-x534.google.com with SMTP id eg48so21506947edb.13; Wed, 15 Mar 2023 14:14:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1678914844; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:from:to:cc:subject:date:message-id:reply-to; bh=ErOHFFfZLiBU7fvFPTfb/G/jVk1aWQz0RyiO/Y7ixFM=; b=jea2BpSYboa38wLSkbg+RAA+ULoibbS9K8kkQQvQV2gEZB0wU1wo1S9dkhdvM1Vi26 WHoUysFF5sJoAkY8Fa3a2RlFxAezlU2mZbzjtCIncRlRObmQOIU2K1K3F/CjoNZQfYwn qZt2FJt90ez6yCooLVlzPtw27UnLYTlagu3TGgSzhrdR8l7vi6rRj1pBa47djPiQtaaN Flp2GyQb1hEDAdD5Udg7YKLrJQ5Z4BqIf78R/ojDetsNns8T0v8Sn/sZYX2RJh/rpro0 /YuYFnH5T7ZsGNj4PxqWAH+FugcekWAH59mpNfJdzN4jDs6nVf8y5f/Z9jPBRHST1ctk yWUw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678914844; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:date:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ErOHFFfZLiBU7fvFPTfb/G/jVk1aWQz0RyiO/Y7ixFM=; b=TXq6gc6Iz3aDOX7Mo2UEa9E7eKl4Z5Kl5/EYBr/u3GIkqcjVLDGmvE69JZsrAlncXI 83LJ8Nt/Lpz3qac4bBUGZtcXjgcSvFD6JjlooeSBPT16gcbBZhuzdB12P007qKoZLB4C 5AmvF18AREsT5gO4s6R38i3tN7Xr9in0T8v2elnR8ozIVv+wtcVMKisQU1CeAeBc+jQl rgSJiFWQTPD4YYb72EIcQzWc2ieC2aMjkyZkHE3SvO6Fea1BffzmINe5B9ZV+OfWhbBu 5Q7av2YlvCFV7FPNBtiNKzwwXZhtlzW5bTTREFi/ODUoT/qHblLD+5p598VjEu9flKrb rXeQ== X-Gm-Message-State: AO0yUKWBfwI1dpWf8KwcIbiDgXgqOCnQvAudURMjXORDqHwYXyDrdGSg xHma15osulDBqCbHTbXa6FE= X-Google-Smtp-Source: AK7set9OP3+L58MFHm0uUycxLPt9A8ha+Zci0ugvBmE4uCM/6aniJQDwnmVJv+/WJpq6/6m7H+Rcrg== X-Received: by 2002:a17:907:c60a:b0:92f:e40d:1489 with SMTP id ud10-20020a170907c60a00b0092fe40d1489mr1409847ejc.61.1678914844452; Wed, 15 Mar 2023 14:14:04 -0700 (PDT) Received: from pc636 ([155.137.26.201]) by smtp.gmail.com with ESMTPSA id rq4-20020a17090788c400b00927341bf69dsm2975472ejc.88.2023.03.15.14.14.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 15 Mar 2023 14:14:04 -0700 (PDT) From: Uladzislau Rezki X-Google-Original-From: Uladzislau Rezki Date: Wed, 15 Mar 2023 22:14:02 +0100 To: Steven Rostedt Cc: Steven Rostedt , Joel Fernandes , 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: References: <20230201150815.409582-1-urezki@gmail.com> <20230315151415.2534e11c@gandalf.local.home> <20230315153448.6914f85b@gandalf.local.home> <20230315162840.106a5b4f@gandalf.local.home> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 15, 2023 at 10:07:22PM +0100, Uladzislau Rezki wrote: > On Wed, Mar 15, 2023 at 04:28:40PM -0400, Steven Rostedt wrote: > > 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"? > > > In that sense there is no need in renaming it. The current name of > single argument is kvfree_rcu(ptr). It is documented that it can sleep. > > According to its name it is clear that it is headless since there > is no a second argument. > Forgot to add. I agree with you that currently it can sleep but it does not mean that a future stays the same, thus there might be an extra need in renaming again. -- Uladzislau Rezki