Re: [PATCH 1/3] rv/reactors: fix lockdep "Invalid wait context" in rv_react()

[Wen Yang <wen.yang@linux.dev>]

On 7/10/26 02:07, Nam Cao wrote:
> Wen Yang <wen.yang@linux.dev> writes:
>> How about a context-sensitive approach, eg:
>>
>>     NMI/hardirq (interrupts masked, scheduler cannot run):
>>       Keep LD_WAIT_FREE.  The false positive cannot arise in this path,
>>       and the original constraint against raw spinlocks is preserved where
>>       it is meaningful.
>>
>>     task/softirq/PREEMPT_RT irq thread (preemptible):
>>       Raise to LD_WAIT_SPIN.  Raw spinlocks become permitted — as Gabriele
>>       note, this is a necessary consequence of any fix in this path.
> 
> I don't get the point. Unless the lock's type is also context-sensitive,
> the reactors still cannot use raw spin locks.
> 

Correct, and that is intentional. The patch is not about enabling raw
spinlocks in callbacks; it is about fixing a false positive in 
preemptible context while preserving LD_WAIT_FREE where it is still 
meaningful.

The lockdep check (kernel/locking/lockdep.c:4901) is:

     if (next_outer > curr_inner)  /* BUG: Invalid wait context */

The false positive in preemptible context:

     rv_react_map (inner = LD_WAIT_FREE = 1)  -->  held by override map
     timer interrupt
       __schedule
          rq->__lock (outer = LD_WAIT_SPIN = 2)
             2 > 1   --->  BUG (while callback itself took no spinlock)

In NMI/hardirq context interrupts are masked; __schedule cannot run, so
rq->__lock is never acquired in this path.  The false positive cannot
arise there, and LD_WAIT_FREE keeps raw spinlocks forbidden:

     raw_spinlock_t (outer = LD_WAIT_SPIN = 2)
     rv_react_map_atomic (inner = LD_WAIT_FREE = 1)
     2 > 1  →  BUG   (intended: hardirq callbacks must be lock-free)


The commit message's "raw spinlocks in callbacks are permitted as a
necessary consequence" is imprecise -- that applies to the preemptible
path only.  I will correct it in v2.


--
Best wishes,
Wen