On Wed, Mar 15, 2023 at 01:16:20PM -0600, Jens Axboe wrote: > On 3/15/23 1:14?PM, Steven Rostedt wrote: > > On Wed, 1 Feb 2023 16:08:06 +0100 > > "Uladzislau Rezki (Sony)" <urezki@xxxxxxxxx> wrote: > > > >> This small series is based on Paul's "dev" branch. Head is 6002817348a1c610dc1b1c01ff81654cdec12be4 > >> it renames a single argument of k[v]free_rcu() to its new k[v]free_rcu_mightsleep() name. > >> > >> 1. > >> The problem is that, recently we have run into a precedent when > >> a user intended to give a second argument to kfree_rcu() API but > >> forgot to do it in a code so a call became as a single argument > >> of kfree_rcu() API. > >> > >> 2. > >> Such mistyping can lead to hidden bags where sleeping is forbidden. > >> > >> 3. > >> _mightsleep() prefix gives much more information for which contexts > >> it can be used for. > > > > My honest opinion is that I hate that name "kvfree_rcu_mightsleep()" ;-) > > > > As I honestly don't know why it might sleep. > > > > I didn't care about the name before, but now that it's touching code I > > maintain I do care ;-) > > > > Why not call it: > > > > kvfree_rcu_synchronize() > > > > ? > > > > As that is much more descriptive of what it does. Especially since these > > ugly names are popping up in my code because kvfree_rcu() replaced a > > rcu_synchronize() in the first place. > > This was my main complaint too, kvfree_rcu_mightsleep() is an absolutely > horrible name for an API... But nobody seemed to care about that! > > I like the _synchronize() suggestion, as it matches other RCU naming. > This is basically about what it does. If you renamed it to "_synchronize()" in reality it would not mean that it always a synchronous call, most of the time it is not whereas the name would point that it is. -- Uladzislau Rezki
