Re: [PATCH v3 1/4] rv/reactors: use context-sensitive lockdep wait type in rv_react()
Gabriele Monaco <[email protected]>
| Newsgroups | org.kernel.vger.linux-trace-kernel,org.kernel.vger.linux-kernel |
|---|---|
| Message-ID | <[email protected]> |
On Mon, 2026-08-17 at 10:18 +0200, Nam Cao wrote: > Gabriele Monaco <[email protected]> writes: > > > On Mon, 2026-08-10 at 01:10 +0800, [email protected] wrote: > > > From: Wen Yang <[email protected]> > > > > > > Reactors must not explicitly take locks, so they should comply with > > > LD_WAIT_FREE. However, reactor callbacks can run with preemption > > > enabled on any kernel (not just PREEMPT_RT). If a timer interrupt > > > fires during the callback, the interrupt exit path schedules and > > > acquires rq->__lock (LD_WAIT_SPIN) while the lockdep override map that > > > declared LD_WAIT_FREE is still held, triggering a spurious > > > "Invalid wait context" warning: > ... > > Anyway, I'd appreciate comments/acks from the other folks in the loop > > Sorry, I do not know enough about lockdep to comment on this. > > FWIW, I would rather just use LD_WAIT_SPIN and keep things > simple. Context-sensitive code paths "feels wrong" to me. Spinning > should either be allowed or forbidden. Making it dynamic "feels like" it > will bring further complications down the road. > > But that's just my intuition. I don't have a strong opinion on this, but since there's no one in the kernel using LD_WAIT_FREE as inner type, that feels like a hint to go down the simple route too and allow LD_WAIT_SPIN. If a reactor ever uses spinlocks, lockdep would already complain on its own if that ends up being an issue, wouldn't it? Gabriele