On Wed, 15 Mar 2023 21:25:16 -0400 "Theodore Ts'o" <tytso@xxxxxxx> wrote: > On Wed, Mar 15, 2023 at 06:08:19PM -0400, Joel Fernandes wrote: > > > > I am doubtful there may be a future where it does not sleep. Why? > > Because you need an rcu_head *somewhere*. > > I think the real problem was that this won't sleep: > > kfree_rcu(ptr, rhf); > > While this *could* sleep: > > kfree_rcu(ptr); > > So the the original sin was to try to make the same mistake that C++ > did --- which is to think that it's good to have functions that have > the same name but different function signatures, and in some cases, > different semantic meanings because they have different implementations. > > Personally, this is why I refuse to use C++ for any of my personal > projects --- this kind of "magic" looks good, but it's a great way to > potentially shoot yourself (or worse, your users) in the foot. > > So separating out the two-argument kfree_rcu() from the one-argument > kfree_rcu(), by renaming the latter to something else is IMHO, a > Really F***** Good Idea. So while, sure, kfree_rcu_mightsleep() might > be a little awkward, the name documents the potential landmind > involved with using that function, that's a good thing. Because do > you really think users will always conscientiously check the > documentation and/or the implementation before using the interface? :-) I agree with everything you said above, and feel that having the same name with two different semantics was not a good way to go. Not to mention, I avoid C++ for basically the same reasons (plus others). > > If you hate that name, one other possibility is to try to use the > two-argument form kfree_rcu() and arrange to *have* a rcu_head in the > structure. That's going to be better from a performance perspective, > and thus kinder to the end user than using rcu_synchronize(). Which is the what I last suggested doing. https://lore.kernel.org/all/20230315183648.5164af0f@xxxxxxxxxxxxxxxxxx/ -- Steve
