+rcu for archives > On Dec 2, 2022, at 7:16 PM, Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > > On Sat, Dec 3, 2022 at 12:12 AM Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: >> >>> On Sat, Dec 3, 2022 at 12:03 AM Paul E. McKenney <paulmck@xxxxxxxxxx> wrote: >>> >>> On Fri, Dec 02, 2022 at 11:49:59PM +0000, Joel Fernandes wrote: >>>> On Fri, Dec 02, 2022 at 05:28:47AM +0000, Eric Dumazet wrote: >>>>> kfree_rcu(1-arg) should be avoided as much as possible, >>>>> since this is only possible from sleepable contexts, >>>>> and incurr extra rcu barriers. >>>>> >>>>> I wish the 1-arg variant of kfree_rcu() would >>>>> get a distinct name, like kfree_rcu_slow() >>>>> to avoid it being abused. >>>> >>>> Hi Eric, >>>> Nice to see your patch. >>>> >>>> Paul, all, regarding Eric's concern, would the following work to warn of >>>> users? Credit to Paul/others for discussing the idea on another thread. One >>>> thing to note here is, this debugging will only be in effect on preemptible >>>> kernels, but should still help catch issues hopefully. >>> >>> Mightn't there be some places where someone needs to invoke >>> single-argument kfree_rcu() in a preemptible context, for example, >>> due to the RCU-protected structure being very small and very numerous? >> >> This could be possible but I am not able to find examples of such >> cases, at the moment. Another approach could be to introduce a >> dedicated API for such cases, where the warning will not fire. And >> keep the warning otherwise. >> >> Example: kfree_rcu_headless() >> With a big comment saying, use only if you are calling from a >> preemptible context and cannot absolutely embed an rcu_head. :-) >> >> Thoughts? >> > > Just to clarify, where I was getting at was to combine both ideas: > 1. new API with suppression of the new warning mentioned above. > 2. old API but add new warning mentioned above. > > Cheers, > > - Joel
