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. > > Or am I missing something subtle here? > > Thanx, Paul
