Re: [PATCH RFC v3 03/13] rcu-tasks: Add a Tasks RCU implementation for reader-marked trampolines

[Frederic Weisbecker <frederic@kernel.org>]

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