On 2020-04-16 13:25:30 [-0700], Paul E. McKenney wrote: > > True, but that is an optimization rather than an absolute necessity. > In addition, most two-argument kfree_rcu() callers will take another slot > from the array that has already been allocated. So one alternative is > to do the allocation only if both interrupts and preemption are enabled. > As long as most kfree_rcu() invocations can allocate, you get good > performance and things work nicely in -rt. This would have to be limited to -RT since spinlock_t disables preemption for !RT. > Another alternative is to check to see what currently invokes kfree_rcu() > and work out what to do about any that are invoked from an environment > in which -rt does not allow memory allocation. And deal with future > additions of kfree_rcu() to such environments. > > Given that most people don't test -rt, the second alternative has > the potential of handing Sebastian an endless stream of bugs that are > kfree_rcu() usage bugs only in -rt. But maybe he is OK with that? > (I wouldn't be, but I will let him speak for himself.) Hopefully we don't have this OOT ride much longer and so it receives more / wider testing once it is merged. However. A grep for current users of kfree_rcu() shows drivers mostly. Almost no core-code. The parts within kernel/ have a spinlock_t acquire so no raw_spinlock_t. This should be fine. > Thanx, Paul Sebastian
