Re: [PATCH v3 1/4] rv/reactors: use context-sensitive lockdep wait type in rv_react()

On Wed, Aug 19, 2026 at 09:12:43AM +0200, Gabriele Monaco wrote:
> 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.

To me the dynamic logic also feels quite complicated.
We could also disable preemption before overriding the lockdep context
when lockdep is enabled to avoid the observed issue.

> > 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?

Only if that reactor is actually triggered by a tracepoint in the wrong context.
This might not happen during testing. This happened to me in my signal reactor
patch, which is why I added the lockdep override.


Thomas