Messages in this thread | | | Date | Wed, 15 Mar 2023 17:37:30 -0700 | From | "Paul E. McKenney" <> | 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@gmail.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@goodmis.org> > >>> Signed-off-by: Uladzislau Rezki (Sony) <urezki@gmail.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
| |