Re: [PATCH] mm/vmstat: flush per-cpu node stats when a node goes offline

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] Recursive acquisition of `cpus_read_lock()` causes a wait-die (AB-BA) reader-writer deadlock with CPU hotplug operations.
- [Medium] Ignoring the `-ENOMEM` return value of `schedule_on_each_cpu()` causes a silent failure, leaving stats permanently orphaned under memory pressure.
--

commit 195f8756c6e31f6d21c338743702f407e4ff93d1
Author: Gregory Price <gourry@gourry.net>

mm/vmstat: flush per-cpu node stats when a node goes offline

This patch flushes per-cpu vmstat deltas to global counters before a node
is offlined. It aims to prevent orphaned statistics that cause throttling
issues by using per-cpu work to synchronize the stats.

> diff --git a/mm/vmstat.c b/mm/vmstat.c
> index f534972f517de..ad77343212d37 100644
> --- a/mm/vmstat.c
> +++ b/mm/vmstat.c
> @@ -941,6 +941,16 @@ void cpu_vm_stats_fold(int cpu)
>  	fold_diff(global_zone_diff, global_node_diff);
>  }
>  
> +static void vmstat_fold_work(struct work_struct *w)
> +{
> +	refresh_cpu_vm_stats(false);
> +}
> +
> +void sync_vm_stats(void)
> +{
> +	schedule_on_each_cpu(vmstat_fold_work);

[Severity: High]
Can this cause a reader-writer deadlock with CPU hotplug operations?

In the memory hot-remove path, try_remove_memory() acquires the
cpu_hotplug_lock for read via mem_hotplug_begin() before calling
try_offline_node():

mm/memory_hotplug.c:try_remove_memory() {
        mem_hotplug_begin();
        ...
        try_offline_node(nid);
}

Then try_offline_node() calls sync_vm_stats(), which bridges into
schedule_on_each_cpu(). The issue is that schedule_on_each_cpu()
unconditionally attempts to acquire the cpu_hotplug_lock for read again:

kernel/workqueue.c:schedule_on_each_cpu() {
        ...
        cpus_read_lock();
}

If a concurrent CPU hotplug operation takes the lock for write between the
first and second read lock acquisitions, it sets the writer-pending flag.
The second read lock attempt will then block waiting for the writer, while
the writer is blocked indefinitely waiting for the first read lock to be
released.

[Severity: Medium]
Does this silently ignore allocation failures?

Under memory pressure, schedule_on_each_cpu() can fail to allocate
the per-cpu work items and return -ENOMEM:

kernel/workqueue.c:schedule_on_each_cpu() {
        works = alloc_percpu(struct work_struct);
        if (!works)
                return -ENOMEM;
        ...
}

Since sync_vm_stats() returns void, this failure is swallowed. If this
allocation fails during try_offline_node(), the stats will not be flushed
and the per-CPU deltas will be permanently orphaned on a later online,
which is the original bug this patch aims to fix.

> +}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260627073107.523499-1-gourry@gourry.net?part=1