On Thu, Oct 31, 2024 at 09:18:52AM +0100, Vlastimil Babka wrote: > On 10/31/24 08:55, Sebastian Andrzej Siewior wrote: > > On 2024-10-31 08:35:45 [+0100], Vlastimil Babka wrote: > >> On 10/31/24 08:21, Sebastian Andrzej Siewior wrote: > >> > On 2024-10-30 16:10:58 [-0700], Paul E. McKenney wrote: > >> >> > >> >> So I need to avoid calling kfree() within an smp_call_function() handler? > >> > > >> > Yes. No kmalloc()/ kfree() in IRQ context. > >> > >> However, isn't this the case that the rule is actually about hardirq context > >> on RT, and most of these operations that are in IRQ context on !RT become > >> the threaded interrupt context on RT, so they are actually fine? Or is smp > >> call callback a hardirq context on RT and thus it really can't do those > >> operations? > > > > interrupt handlers as of request_irq() are forced-threaded on RT so you > > can do kmalloc()/ kfree() there. smp_call_function.*() on the other hand > > are not threaded and invoked directly within the IRQ context. > > Makes sense, thanks. > > So how comes rcutorture wasn't deadlocking on RT already, is it (or RCU > itself) doing anything differently there that avoids the kfree() from > smp_call_function() handler? This was scftorture rather than rcutorture. While I know of others who regularly run rcutorture, to the best of my knowledge I am the only one who ever runs scftorture, which tests smp_call_function(), its friends, and its diagnostics. Thanx, Paul
