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". -- Vlad Rezki
