On Wed, Sep 16, 2026 at 09:37:50PM +0800, Donglin Peng wrote:
> On Sat, Sep 12, 2026 at 12:06 AM Paul E. McKenney <[email protected]> wrote:
> >
> > On Fri, Sep 04, 2026 at 08:24:05PM +0800, Peng Donglin wrote:
> > > On 1/5/26 11:21, Donglin Peng wrote:
> > > > From: Donglin Peng <[email protected]>
> > > >
> > > > The RCU stall warning message includes an "idle=" field to indicate
> > > > the dyntick-idle state of a CPU. According to
> > > > Documentation/RCU/stallwarn.rst,
> > > > the hexadecimal number before the first '/' represents the low-order 16
> > > > bits of the dynticks counter. An even value denotes that the CPU is in
> > > > dyntick-idle mode, while an odd value indicates otherwise.
> > > >
> > > > This was valid until commit 171476775d32 ("context_tracking: Convert
> > > > state to atomic_t"),
> > > > which merged the context-tracking state and dynticks counter into a
> > > > single atomic variable. In the new layout, the dynticks counter occupies
> > > > the higher bits starting from CT_RCU_WATCHING_START.
> > > >
> > > > However, the current stall warning code prints the value from
> > > > `ct_rcu_watching_cpu()`, which returns `atomic_read(&ct->state) &
> > > > CT_RCU_WATCHING_MASK`. This masks out (clears) the lower state bits,
> > > > resulting in a value that is always even. This obscures the CPU's true
> > > > idle state and makes the output inconsistent with the documentation.
> > > >
> > > > To restore consistency between the code's output and the documentation,
> > > > shift the atomic value right by CT_RCU_WATCHING_START bits before
> > > > printing.
> > > > This extracts and displays only the relevant dynticks counter portion,
> > > > allowing the parity (even/odd) to correctly reflect the CPU's
> > > > dyntick-idle
> > > > state.
> > > >
> > > > Fixes: 171476775d32 ("context_tracking: Convert state to atomic_t")
> > > > Signed-off-by: Donglin Peng <[email protected]>
> > > > Reviewed-by: Joel Fernandes <[email protected]>
> > > > ---
> > > > v2:
> > > > - Use CT_RCU_WATCHING_START to replace ilog2(CT_RCU_WATCHING) to clean
> > > > up the code, thanks to Zqiang.
> > > > - Clarify the commit message.
> > > > ---
> > > > kernel/rcu/tree_stall.h | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/kernel/rcu/tree_stall.h b/kernel/rcu/tree_stall.h
> > > > index b67532cb8770..fd9d7fd6e17c 100644
> > > > --- a/kernel/rcu/tree_stall.h
> > > > +++ b/kernel/rcu/tree_stall.h
> > > > @@ -555,7 +555,7 @@ static void print_cpu_stall_info(int cpu)
> > > > rdp->rcu_iw_pending ? (int)min(delta, 9UL) + '0' :
> > > > "!."[!delta],
> > > > ticks_value, ticks_title,
> > > > - ct_rcu_watching_cpu(cpu) & 0xffff,
> > > > + (ct_rcu_watching_cpu(cpu) >> CT_RCU_WATCHING_START) & 0xffff,
> > > > ct_nesting_cpu(cpu), ct_nmi_nesting_cpu(cpu),
> > > > rdp->softirq_snap, kstat_softirqs_cpu(RCU_SOFTIRQ, cpu),
> > > > data_race(rcu_state.n_force_qs) -
> > > > rcu_state.n_force_qs_gpstart,
> > >
> > > Gentle ping on this patch. Thanks!
> >
> > The advantage of the current code is that the CT_STATE_KERNEL,
> > CT_STATE_IDLE, CT_STATE_USER, and CT_STATE_GUEST information is visible
> > in the lower two bits of that hex number.
> >
> > Now, if you wanted to print that information symbolically and then
> > shift down the counter, that might well be a valuable improvement.
> > Given corresponding updates to stallwarn.rst, of course.
>
> Thanks, that makes sense. I'll print the state symbolically, shift down
> the counter, update stallwarn.rst accordingly, and send a v3.
Sounds good, and looking forward to it!
Thanx, Paul
> > Or am I missing something subtle here?
> >
> > Thanx, Paul
