On Thu, Apr 16, 2020 at 10:05:57PM +0200, Uladzislau Rezki wrote: > On Thu, Apr 16, 2020 at 12:53:27PM -0700, Paul E. McKenney wrote: > > On Thu, Apr 16, 2020 at 03:26:23PM -0400, Steven Rostedt wrote: > > > On Thu, 16 Apr 2020 14:59:34 -0400 > > > Joel Fernandes <joel@xxxxxxxxxxxxxxxxx> wrote: > > > > > > > But, then will it be safe for kfree_rcu() callers from hard IRQ context to > > > > call this in PREEMPT_RT? That could would just break then as you cannot sleep > > > > in hard IRQ context even on PREEMPT_RT. > > > > > > But where in PREEMPT_RT would it be called in hard IRQ context? > > > > I believe that call_rcu() is invoked with raw spinlocks held, so we should > > allow kfree_rcu() to be invoked from similar contexts. It obviously > > cannot allocate memory in such contexts, so perhaps the rule is that > > single-argument kfree_rcu() cannot be invoked within hard IRQ contexts > > or with raw spinlocks held. In those contexts, you would instead need > > to invoke two-argument kfree_rcu(), which never needs to allocate memory. > > > > Seem reasonable? > > > Paul, just to make it more clear, even invoking two arguments fkree_rcu() > currently does an allocation. We maintain an array that contains pointers > for "bulk logic". 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. 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.) Thanx, Paul