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
