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

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

On 7/8/26 23:47, Thomas Weißschuh wrote:
> On Mon, Jul 06, 2026 at 04:02:08PM +0200, Gabriele Monaco wrote:
>> On Tue, 2026-06-23 at 11:38 +0200, Thomas Weißschuh wrote:
>>> This now allows reactors to take (raw) spinlocks. The original idea was
>>> to not allow that as a reactor can be called from LD_WAIT_FREE context.
>>> So I am not sure this is the right fix. Not that I have a better one
>>> available right now.
>>
>> As far as I understand it, LD_WAIT_FREE is fairly impossible to apply on
>> preemptible code (here we see it hit by an interrupt).
>>
>> Since we kind of have to allow raw spinlock to avoid this (even if we don't take
>> them explicitly), why wouldn't a reactor ever be allowed to take raw spinlocks?
>>
>> Technically it wouldn't be wrong to take locks from RV monitors, although most
>> monitors don't do it explicitly.
>> If we ever happen to take the wrong lock explicitly from a reactor triggered by
>> a nasty event (e.g. sched_switch), I believe lockdep would still be complaining
>> down that path, so we probably don't need to be too strict in rv_react().
>>
>> Obviously we don't want to disable interrutps for LD_WAIT_FREE to hold either.
>>
>> Am I missing something?
> 
> No, I was just very confused.
> Let's go ahead with this.
> 
> 

Hi,

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.


like this:


+       static DEFINE_WAIT_OVERRIDE_MAP(rv_react_map,        LD_WAIT_SPIN);
+       static DEFINE_WAIT_OVERRIDE_MAP(rv_react_map_atomic, LD_WAIT_FREE);
+       struct lockdep_map *map;
...
+       map = (in_nmi() || in_hardirq()) ? &rv_react_map_atomic : 
&rv_react_map;

-       lock_map_acquire_try(&rv_react_map);
+       lock_map_acquire_try(map);
...
         monitor->react(msg, args);
-       lock_map_release(&rv_react_map);
+       lock_map_release(map);


--
Best wishes,
Wen