On Wed, Mar 15, 2023 at 09:25:16PM -0400, Theodore Ts'o 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. Guilty to charges as read. ;-) > 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? :-) > > 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(). The original reason for single-argument kvfree_rcu() was to avoid the need for that rcu_head. The use case was a small data structure with an extremely high population. Thanx, Paul
