On Wed, Mar 15, 2023 at 11:44 PM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: > > On Wed, Mar 15, 2023 at 10:23:23PM -0400, Steven Rostedt wrote: > > On Wed, 15 Mar 2023 17:37:30 -0700 > > "Paul E. McKenney" <paulmck@xxxxxxxxxx> 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. > > kvfree_rcu_alloc_head()? > kvfree_rcu_dynhead()? > kvfree_rcu_gearhead()? > kvfree_rcu_radiohead()? > kvfree_rcu_getahead()? > > I don't know about you guys, but to me, kvfree_rcu_mightsleep() is > sounding better and better by comparison... Indeed, and one could argue that "headless" sounds like something out of a horror movie ;-). Which of course does match the situation when the API is applied incorrectly. - Joel
