Le Wed, Sep 16, 2026 at 08:41:36AM -0700, Paul E. McKenney a écrit :
> On Wed, Sep 16, 2026 at 05:23:31PM +0200, Frederic Weisbecker wrote:
> > Le Wed, Sep 16, 2026 at 07:55:02AM -0700, Paul E. McKenney a écrit :
> > > Perhaps in rcu_core() in kernels booted with use_softirq? I am thinking
> > > specifically of the checks for deferred quiescent states. I don't (yet)
> > > see a need to modify rcu_check_quiescent_state().
> > >
> > > Maybe other places as well. ;-)
> >
> > Hmm this tracking would have to happen on preempt_schedule() just like we
> > do for PREEMPT_RCU. Or am I missing something? And then we would need a
> > list scan of those tasks.
>
> I am thinking of the case where a trampoline is interrupted before entering
> (or after leaving) its RCU Tasks Trace read-side critical section. Then
> there is a softirq handler on the back of that interrupt handler, and
> RCU_SOFTIRQ is invoked, calling rcu_core(). Specifically:
>
> /* Report any deferred quiescent states if preemption enabled. */
> if (IS_ENABLED(CONFIG_PREEMPT_COUNT) && (!(preempt_count() &
> PREEMPT_MASK))) {
> rcu_preempt_deferred_qs(current);
> } else if (rcu_preempt_need_deferred_qs(current)) {
> guard(irqsave)();
> set_need_resched_current();
> }
>
> Preemption is enabled, but we should not report a quiescent state because
> we have interrupted a trampoline. Correct?
Right!
> > Or we can build the blocked task list handling, that we already have for
> > PREEMPT_RCU,
> > when CONFIG_RCU_TASKS && !CONFIG_PREEMPT_RCU. We would just only add tasks
> > when
> > preempted in .text.rcu_no_qs since rcu_read_lock() would still disable
> > preemption on normal explicit readers. So I wouldn't expect more overhead
> > due to
> > that blocked list tracking built since it would rarely track tasks.
>
> Yes, we could avoid the list of tasks by treating the preemption within
> the trampoline the same as preemption within an RCU read-side critical
> section, but there might not be an rcu_read_unlock() to clean up.
> Which could be a problem.
Ah yes, good point.
>
> Trampolines that transfer control to tracing code could supply the needed
> cleanup call. But last I checked, there were trampolines that transferred
> directly back to the original code, with no opportunity for cleaning up.
>
> Or am I still missing a trick here?
You're right. So we'll indeed need to reuse the deferred qs points here.
Thanks.
--
Frederic Weisbecker
SUSE Labs
