[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <60f55a5d-213f-46b7-9294-c37f10f98252@paulmck-laptop>
Date: Wed, 15 Mar 2023 17:37:30 -0700
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Jens Axboe <axboe@...nel.dk>
Cc: Steven Rostedt <rostedt@...dmis.org>,
Uladzislau Rezki <urezki@...il.com>,
LKML <linux-kernel@...r.kernel.org>, RCU <rcu@...r.kernel.org>,
Oleksiy Avramchenko <oleksiy.avramchenko@...y.com>,
Philipp Reisner <philipp.reisner@...bit.com>,
Bryan Tan <bryantan@...are.com>,
Eric Dumazet <edumazet@...gle.com>,
Bob Pearson <rpearsonhpe@...il.com>,
Ariel Levkovich <lariel@...dia.com>,
Theodore Ts'o <tytso@....edu>, Julian Anastasov <ja@....bg>
Subject: Re: [PATCH 04/13] tracing: Rename kvfree_rcu() to
kvfree_rcu_mightsleep()
On Wed, Mar 15, 2023 at 05:19:18PM -0600, Jens Axboe wrote:
> On 3/15/23 4:36 PM, Steven Rostedt wrote:
> > On Thu, 9 Mar 2023 14:45:21 +0100
> > Uladzislau Rezki <urezki@...il.com> wrote:
> >
> >>> The kvfree_rcu()'s single argument name is deprecated therefore
> >>> rename it to kvfree_rcu_mightsleep() variant. The goal is explicitly
> >>> underline that it is for sleepable contexts.
> >>>
> >>> Cc: Steven Rostedt (VMware) <rostedt@...dmis.org>
> >>> Signed-off-by: Uladzislau Rezki (Sony) <urezki@...il.com>
> >>>
> >> Could you please add you reviwed-by or Acked-by tags so we can bring
> >> our series with renaming for the next merge window?
> >
> > I don't know. Perhaps we should just apply this patch and not worry about
> > sleeping and whatnot.
That does work, and I am guessing that the size increase is not a big
problem for you there.
> 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! ;-)
Thanx, Paul
Powered by blists - more mailing lists