On 7/10/26 02:07, Nam Cao wrote:
Wen Yang <[email protected]> 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
