On 2026-03-17 06:34:26 [-0700], Paul E. McKenney wrote:
> Hello!
Hi,
> Kumar Kartikeya Dwivedi (CCed) privately reported a bug in
> my implementation of the RCU Tasks Trace API in terms of SRCU-fast.
> You see, I forgot to ask what contexts call_rcu_tasks_trace() is called
> from, and it turns out that it can in fact be called with the scheduler
> pi/rq locks held. This results in a deadlock when SRCU-fast invokes the
> scheduler in order to start the SRCU-fast grace period. So RCU needs
> a fix to my fix found here:
>
> b540c63cf6e5 ("srcu: Use raw spinlocks so call_srcu() can be used under
> preempt_disable()")
I can't find it. I looked in next and the rcu tree.
> Sebastian, the PREEMPT_RT aspect is that lockdep does not complain
> about acquisition of non-raw spinlocks from preemption-disabled regions
> of code. This might be intentional, for example, there might be large
> bodies of Linux-kernel code that frequently acquire non-raw spinlocks
> from preemption-disabled regions of code, but which are never part of
> PREEMPT_RT kernels. Otherwise, it might be good for lockdep to diagnose
> this sort of thing.
The point is you don't know where this preempt_disable() is coming from
on !RT. It might be part of spinlock_t it might be explicit. We only
have the might_sleep() on PREEMPT_RT.
To catch this we would have to iterate over all held locks, compare the
expected preemption level with the current and account for possible
corner cases such as in-IRQ will be one higher and so on…
However, if you hold a raw_spinlock_t (such as rq/pi) then are asking
for a spinlock_t lockdep should respond with a
| BUG: Invalid wait context
report.
> Back to the actual bug, that call_srcu() now needs to tolerate being called
> with scheduler rq/pi locks held...
This is because it is called from sched_ext BPF callbacks?
> The straightforward (but perhaps broken) way to resolve this is to make
> srcu_gp_start_if_needed() defer invoking the scheduler, similar to the
Quick question. If srcu_gp_start_if_needed() can be invoked from a
preempt-disabled section (due to rq/pi lock) then
spin_lock_irqsave_sdp_contention(sdp, &flags);
does not work, right?
> way that vanilla RCU's call_rcu_core() function takes an early exit if
> interrupts are disabled. Of course, vanilla RCU can rely on things like
> the scheduling-clock interrupt to start any needed grace periods [1],
> but SRCU will instead need to manually defer this work, perhaps using
> workqueues or IRQ work.
>
> In addition, rcutorture needs to be upgraded to sometimes invoke
> ->call() with the scheduler pi lock held, but this change is not fixing
> a regression, so could be deferred. (There is already code in rcutorture
> that invokes the readers while holding a scheduler pi lock.)
>
> Given that RCU for this week through the end of March belongs to you guys,
> if one of you can get this done by end of day Thursday, London time,
> very good! Otherwise, I can put something together.
>
> Please let me know!
Given that the current locking does allow it and lockdep should have
complained, I am curious if we could rule that out ;)
>
> Thanx, Paul [2]
>
> [1] The exceptions to this rule being handled by the call to
> invoke_rcu_core() when rcu_is_watching() returns false.
>
> [2] Ah, and should vanilla RCU's call_rcu() be invokable from NMI
> handlers? Or should there be a call_rcu_nmi() for this purpose?
> Or should we continue to have its callers check in_nmi() when needed?
Did someone ask for this?
Sebastian
