Date:   Wed, 15 Mar 2023 22:23:23 -0400
From:   Steven Rostedt <rostedt@goodmis.org>
To:     "Paul E. McKenney" <paulmck@kernel.org>
Cc:     Jens Axboe <axboe@kernel.dk>, Uladzislau Rezki <urezki@gmail.com>,
        LKML <linux-kernel@vger.kernel.org>, RCU <rcu@vger.kernel.org>,
        Oleksiy Avramchenko <oleksiy.avramchenko@sony.com>,
        Philipp Reisner <philipp.reisner@linbit.com>,
        Bryan Tan <bryantan@vmware.com>,
        Eric Dumazet <edumazet@google.com>,
        Bob Pearson <rpearsonhpe@gmail.com>,
        Ariel Levkovich <lariel@nvidia.com>,
        Theodore Ts'o <tytso@mit.edu>, Julian Anastasov <ja@ssi.bg>
Subject: Re: [PATCH 04/13] tracing: Rename kvfree_rcu() to
 kvfree_rcu_mightsleep()
Message-ID: <20230315222323.7afe82e7@gandalf.local.home>
In-Reply-To: <60f55a5d-213f-46b7-9294-c37f10f98252@paulmck-laptop>
References: <20230201150815.409582-1-urezki@gmail.com>
        <20230201150815.409582-5-urezki@gmail.com>
        <ZAni8Q1NW9cWrvHJ@pc636>
        <20230315183648.5164af0f@gandalf.local.home>
        <d404a6b6-4ff9-930a-1cdc-fd730270fbe7@kernel.dk>
        <60f55a5d-213f-46b7-9294-c37f10f98252@paulmck-laptop>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Precedence: bulk

On Wed, 15 Mar 2023 17:37:30 -0700
"Paul E. McKenney" <paulmck@kernel.org> wrote:

> 
> That does work, and I am guessing that the size increase is not a big
> problem for you there.

Well, I was fine with it as long as it stayed in the headers, where
ugliness is warmly welcomed. Just ask all the #ifdefs.

> 
> > That's a cop out, just removing the one case you care about. Fact is
> > the naming is awful, and the 1/2 argument thing is making it worse.
> > If a big change is warranted, why not do it right and ACTUALLY
> > get it right?  
> 
> You both do realize that the kvfree_rcu_mightsleep() definition is
> already in mainline, right?
> 
> Anyway, to sum up, kvfree_rcu_mightsleep()--or whatever the entire
> community eventually decides to name it--can do any of the following:
> 
> 1.	Put the pointer into an already allocated array of pointers.
> 
> 2.	Allocate a new array of pointers, have the allocation succeed
> 	without sleeping, then put the pointer into an already allocated
> 	array of pointers.
> 
> 3.	Allocate a new array of pointers, have the allocation succeed
> 	after sleeping, then put the pointer into an already allocated
> 	array of pointers.
> 
> 4.	Attempt to allocate a new array of pointers, have the allocation
> 	fail (presumably after sleeping), then invoke synchronize_rcu()
> 	directly.
> 
> Too much fun!  ;-)
> 

  kvfree_rcu_kitchen_sink() ?

  kvfree_rcu_goldie_locks()?

I honestly like the name "headless" as that perfectly describes the
difference between kvfree_rcu(arg1, arg2) and kvfree_rcu(arg1).

Whereas mightsleep() is confusing to me because it doesn't tell me why
kvfree_rcu() has two args and kvfree_rcu_mightsleep() has only one.
Usually, code that has two sleep variants is about limiting the
functionality of the atomic friendly one.

-- Steve