Re: [PATCH] iommupt/kunit: Read an exact NR_SECONDARY_PAGETABLE snapshot for the leak check

[Jason Gunthorpe <jgg@nvidia.com>]

On Fri, Oct 16, 2026 at 09:12:29AM +0800, fangyu.yu@linux.alibaba.com wrote:
> >> +/*
> >> + * The global NR_SECONDARY_PAGETABLE counter is batched per-CPU and folded
> >> + * into the global value asynchronously, sum the global value and the per-CPU
> >> + * deltas to get an exact snapshot.
> >> + *
> >> + * The global value must be read without the clamp of global_node_page_state():
> >> + * the raw counter is transiently negative whenever a folded free batch
> >> + * outweighs allocation deltas still pending on other CPUs, and clamping
> >> + * before adding the deltas back would overestimate and report phantom leaks.
> >> + * global_node_page_state_monotonic() is normally reserved for monotonic
> >> + * counters because a raw negative read is garbage as a page count, but the
> >> + * sum with the pending deltas always restores the exact non-negative value.
> >> + */
> >> +static unsigned long pt_kunit_nr_secondary_pagetable(void)
> >> +{
> >> +	unsigned long nr = global_node_page_state_monotonic(NR_SECONDARY_PAGETABLE);
> >> +
> >> +#ifdef CONFIG_SMP
> >> +	int nid, cpu;
> >> +
> >> +	cpus_read_lock();
> >> +	for_each_online_cpu(cpu)
> >> +		for_each_online_node(nid)
> >> +			nr += per_cpu_ptr(NODE_DATA(nid)->per_cpu_nodestats,
> >> +					  cpu)->vm_node_stat_diff[NR_SECONDARY_PAGETABLE];
> >> +	cpus_read_unlock();
> >> +#endif
> >
> >This should not be outside the mm code that manages this data
> >structure.
> >
> 
> You're right. However, I couldn't find a way to solve this by
> modifying only the iommupt KUnit code.
> 
> >I think the kunit runner executes this in some environment that
> >doesn't trigger this delay? At least I've never seen this assert?
> >
> 
> I can reproduce the assert stably on an x86 machine by booting a
> 4-core riscv64 QEMU.

Possibly kunit runner doesn't enable smp. Can you investigate? Maybe
we can solve this by disabling the check on !SMP

Jason