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

[Jason Gunthorpe]

On Thu, Oct 15, 2026 at 09:20:24PM +0800, fangyu.yu@xxxxxxxxxxxxxxxxx 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.

I think the kunit runner executes this in some environment that
doesn't trigger this delay? At least I've never seen this assert?

Maybe the test should just be ifdef'd off if that isn't the case?

Jason