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

[fangyu . yu]

>> +/*
>> + * 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.

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