group_cpus_evenly() builds the managed-IRQ affinity spread used by
multi-queue devices such as NVMe. That spread is meant to be a property
of the static CPU topology: it walks cpu_present_mask and then
cpu_possible_mask so every hardware queue owns a fixed set of CPUs,
including CPUs that are offline at the time. A driver depends on that
partition staying stable across re-computation - the CPUs a queue is
given at probe must still describe the same queue after the device is
later reset and its affinity recomputed.

On an AMD system that stability breaks across an s2idle cycle. With CPUs
3-11 offlined and only CPUs 0-2 left online, the machine is suspended to
s2idle and resumed. The NVMe controller uses the simple-suspend quirk, so
resume fully re-initialises it and recomputes the affinity spread. The
system then hangs for roughly two minutes and stays sluggish afterwards,
the controller only making progress through its command-timeout poll:

  nvme nvme0: I/O tag 898 (3382) QID 9 timeout, completion polled
  nvme nvme0: I/O tag 398 (618e) QID 11 timeout, completion polled

QID 9 and QID 11 are the queues whose CPUs were offline when the spread
was recomputed. "completion polled" means the commands did finish in
hardware, but their interrupts were never delivered to a CPU that was
watching the queue, so nothing reaped them until the timeout fired.

It happens because commit 89802ca36c96 ("lib/group_cpus: make group CPU
cluster aware") derives the cluster groups from topology_cluster_cpumask(),
which lists only the cluster siblings that are online when it is called.
The resulting partition therefore depends on the transient online mask
rather than on the topology alone. Recomputed on resume while the non-boot
CPUs are still offline, it no longer matches the boot-time partition, and a
queue is left with an affinity that does not cover the CPU it is meant to
serve once that CPU comes back online. The dependence is on the online
mask, not on any AMD-specific behaviour, so the same stall is reproducible
on Intel platforms as well.

Make the cluster grouping depend on the complete cluster topology rather
than on whichever CPUs happen to be online. Snapshot the cluster masks
once while every CPU is online and reuse that view for every later spread.
A fully-online view is the complete cluster membership, so the partition
derived from it is identical no matter which CPUs are online when the
controller is reset, which is exactly the invariance the callers already
assume.

Fixes: 89802ca36c96 ("lib/group_cpus: make group CPU cluster aware")
Cc: stable@vger.kernel.org
Signed-off-by: Vishal Badole <Vishal.Badole@amd.com>
---
 lib/group_cpus.c | 84 ++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 82 insertions(+), 2 deletions(-)

diff --git a/lib/group_cpus.c b/lib/group_cpus.c
index e6e18d7a49bb..3ec9b2c4c908 100644
--- a/lib/group_cpus.c
+++ b/lib/group_cpus.c
@@ -6,6 +6,7 @@
 #include <linux/kernel.h>
 #include <linux/slab.h>
 #include <linux/cpu.h>
+#include <linux/mutex.h>
 #include <linux/sort.h>
 #include <linux/group_cpus.h>
 
@@ -286,6 +287,74 @@ static void assign_cpus_to_groups(unsigned int ncpus,
 	}
 }
 
+/*
+ * topology_cluster_cpumask() only lists the cluster siblings that are online,
+ * so group_cpus_evenly() would compute a different managed-IRQ partition when
+ * recomputed with CPUs offline (e.g. an NVMe reset across s2idle), steering a
+ * queue's IRQ away from the CPU it serves.
+ *
+ * Snapshot the cluster masks once, on the first spread seen with every CPU
+ * online, and reuse it so the grouping stays stable. If no snapshot exists
+ * (partial boot via maxcpus=/nosmp, or allocation failure) the cluster path
+ * is skipped and the plain present/possible spread is used. Only the cluster
+ * path is stabilised; grp_spread_init_one()'s sibling mask is unchanged. The
+ * snapshot lives for the system lifetime and is not refreshed for CPUs
+ * hot-added after boot.
+ */
+static cpumask_var_t *cluster_snapshot;
+static bool cluster_snapshot_ready;
+static DEFINE_MUTEX(cluster_snapshot_lock);
+
+static void capture_cluster_snapshot(void)
+{
+	cpumask_var_t *snapshot;
+	unsigned int cpu;
+
+	/* Pairs with the smp_store_release() below. */
+	if (smp_load_acquire(&cluster_snapshot_ready))
+		return;
+
+	/*
+	 * Only a fully-online view is the complete cluster membership; if any
+	 * CPU is offline, retry on a later call. The read races hotplug, but a
+	 * wrong guess only defers the capture.
+	 */
+	if (!data_race(cpumask_equal(cpu_possible_mask, cpu_online_mask)))
+		return;
+
+	mutex_lock(&cluster_snapshot_lock);
+	if (cluster_snapshot_ready)
+		goto out;
+
+	snapshot = kcalloc(nr_cpu_ids, sizeof(*snapshot), GFP_KERNEL);
+	if (!snapshot)
+		goto out;
+
+	for_each_possible_cpu(cpu) {
+		if (!zalloc_cpumask_var(&snapshot[cpu], GFP_KERNEL)) {
+			while (cpu--)
+				free_cpumask_var(snapshot[cpu]);
+			kfree(snapshot);
+			goto out;
+		}
+		cpumask_copy(snapshot[cpu], topology_cluster_cpumask(cpu));
+	}
+
+	/* Drop it if a CPU changed state mid-copy; never latch a torn view. */
+	if (!data_race(cpumask_equal(cpu_possible_mask, cpu_online_mask))) {
+		for_each_possible_cpu(cpu)
+			free_cpumask_var(snapshot[cpu]);
+		kfree(snapshot);
+		goto out;
+	}
+
+	cluster_snapshot = snapshot;
+	/* Publish the filled snapshot before the ready flag. */
+	smp_store_release(&cluster_snapshot_ready, true);
+out:
+	mutex_unlock(&cluster_snapshot_lock);
+}
+
 static int alloc_cluster_groups(unsigned int ncpus,
 				unsigned int ngroups,
 				struct cpumask *node_cpumask,
@@ -299,6 +368,17 @@ static int alloc_cluster_groups(unsigned int ncpus,
 	const struct cpumask **clusters;
 	struct node_groups *cluster_groups;
 
+	/*
+	 * Capture on the first fully-online spread (normally the first device
+	 * probe); later spreads reuse it. Sample the ready flag once so both
+	 * loops below use one consistent source.
+	 */
+	capture_cluster_snapshot();
+
+	/* Pairs with the smp_store_release() in capture_cluster_snapshot(). */
+	if (!smp_load_acquire(&cluster_snapshot_ready))
+		goto no_cluster;
+
 	cpumask_copy(msk, node_cpumask);
 
 	/* Probe how many clusters in this node. */
@@ -307,7 +387,7 @@ static int alloc_cluster_groups(unsigned int ncpus,
 		if (cpu >= nr_cpu_ids)
 			break;
 
-		cluster_mask = topology_cluster_cpumask(cpu);
+		cluster_mask = cluster_snapshot[cpu];
 		if (!cpumask_weight(cluster_mask))
 			goto no_cluster;
 		/* Clean out CPUs on the same cluster. */
@@ -331,7 +411,7 @@ static int alloc_cluster_groups(unsigned int ncpus,
 	cpumask_copy(msk, node_cpumask);
 	for (n = 0; n < ncluster; n++) {
 		cpu = cpumask_first(msk);
-		cluster_mask = topology_cluster_cpumask(cpu);
+		cluster_mask = cluster_snapshot[cpu];
 		nc = cpumask_weight_and(cluster_mask, node_cpumask);
 		clusters[n] = cluster_mask;
 		cluster_groups[n].id = n;
-- 
2.34.1

On Fri, 7 Aug 2026 13:06:12 +0530 Vishal Badole <Vishal.Badole@amd.com> wrote:

> group_cpus_evenly() builds the managed-IRQ affinity spread used by
> multi-queue devices such as NVMe. That spread is meant to be a property
> of the static CPU topology: it walks cpu_present_mask and then
> cpu_possible_mask so every hardware queue owns a fixed set of CPUs,
> including CPUs that are offline at the time. A driver depends on that
> partition staying stable across re-computation - the CPUs a queue is
> given at probe must still describe the same queue after the device is
> later reset and its affinity recomputed.
> 
> On an AMD system that stability breaks across an s2idle cycle. With CPUs
> 3-11 offlined and only CPUs 0-2 left online, the machine is suspended to
> s2idle and resumed. The NVMe controller uses the simple-suspend quirk, so
> resume fully re-initialises it and recomputes the affinity spread. The
> system then hangs for roughly two minutes and stays sluggish afterwards,
> the controller only making progress through its command-timeout poll:
> 
>   nvme nvme0: I/O tag 898 (3382) QID 9 timeout, completion polled
>   nvme nvme0: I/O tag 398 (618e) QID 11 timeout, completion polled
> 
> QID 9 and QID 11 are the queues whose CPUs were offline when the spread
> was recomputed. "completion polled" means the commands did finish in
> hardware, but their interrupts were never delivered to a CPU that was
> watching the queue, so nothing reaped them until the timeout fired.
> 
> It happens because commit 89802ca36c96 ("lib/group_cpus: make group CPU
> cluster aware") derives the cluster groups from topology_cluster_cpumask(),
> which lists only the cluster siblings that are online when it is called.
> The resulting partition therefore depends on the transient online mask
> rather than on the topology alone. Recomputed on resume while the non-boot
> CPUs are still offline, it no longer matches the boot-time partition, and a
> queue is left with an affinity that does not cover the CPU it is meant to
> serve once that CPU comes back online. The dependence is on the online
> mask, not on any AMD-specific behaviour, so the same stall is reproducible
> on Intel platforms as well.

Thanks for the careful description of what is wrong.  It helps.

And things do sounds very wrong.  Could people@intel please prioritize
their review and testing of this fix?

> Make the cluster grouping depend on the complete cluster topology rather
> than on whichever CPUs happen to be online. Snapshot the cluster masks
> once while every CPU is online and reuse that view for every later spread.
> A fully-online view is the complete cluster membership, so the partition
> derived from it is identical no matter which CPUs are online when the
> controller is reset, which is exactly the invariance the callers already
> assume.
> 
> ...
>
> +	/*
> +	 * Only a fully-online view is the complete cluster membership; if any

minor: the above sentence is hard to understand.

> +	if (!data_race(cpumask_equal(cpu_possible_mask, cpu_online_mask)))

AI review suggests using cpu_present_mask here:

	https://sashiko.dev/#/patchset/20260807073612.3711269-1-Vishal.Badole@amd.com

> Thanks for the careful description of what is wrong.  It helps.
> And things do sounds very wrong.  Could people@intel please prioritize their review and testing of this fix?

Thanks for highlighting this issue and for the detailed analysis from Vishal.
I will help review and validate this patch and will follow up on the thread with any findings or feedback.

On 8/8/2026 2:08 AM, Andrew Morton wrote:
> On Fri, 7 Aug 2026 13:06:12 +0530 Vishal Badole <Vishal.Badole@amd.com> wrote:
> 
>> group_cpus_evenly() builds the managed-IRQ affinity spread used by
>> multi-queue devices such as NVMe. That spread is meant to be a property
>> of the static CPU topology: it walks cpu_present_mask and then
>> cpu_possible_mask so every hardware queue owns a fixed set of CPUs,
>> including CPUs that are offline at the time. A driver depends on that
>> partition staying stable across re-computation - the CPUs a queue is
>> given at probe must still describe the same queue after the device is
>> later reset and its affinity recomputed.
>>
>> On an AMD system that stability breaks across an s2idle cycle. With CPUs
>> 3-11 offlined and only CPUs 0-2 left online, the machine is suspended to
>> s2idle and resumed. The NVMe controller uses the simple-suspend quirk, so
>> resume fully re-initialises it and recomputes the affinity spread. The
>> system then hangs for roughly two minutes and stays sluggish afterwards,
>> the controller only making progress through its command-timeout poll:
>>
>>    nvme nvme0: I/O tag 898 (3382) QID 9 timeout, completion polled
>>    nvme nvme0: I/O tag 398 (618e) QID 11 timeout, completion polled
>>
>> QID 9 and QID 11 are the queues whose CPUs were offline when the spread
>> was recomputed. "completion polled" means the commands did finish in
>> hardware, but their interrupts were never delivered to a CPU that was
>> watching the queue, so nothing reaped them until the timeout fired.
>>
>> It happens because commit 89802ca36c96 ("lib/group_cpus: make group CPU
>> cluster aware") derives the cluster groups from topology_cluster_cpumask(),
>> which lists only the cluster siblings that are online when it is called.
>> The resulting partition therefore depends on the transient online mask
>> rather than on the topology alone. Recomputed on resume while the non-boot
>> CPUs are still offline, it no longer matches the boot-time partition, and a
>> queue is left with an affinity that does not cover the CPU it is meant to
>> serve once that CPU comes back online. The dependence is on the online
>> mask, not on any AMD-specific behaviour, so the same stall is reproducible
>> on Intel platforms as well.
> 
> Thanks for the careful description of what is wrong.  It helps.
> 
> And things do sounds very wrong.  Could people@intel please prioritize
> their review and testing of this fix?
> 
>> Make the cluster grouping depend on the complete cluster topology rather
>> than on whichever CPUs happen to be online. Snapshot the cluster masks
>> once while every CPU is online and reuse that view for every later spread.
>> A fully-online view is the complete cluster membership, so the partition
>> derived from it is identical no matter which CPUs are online when the
>> controller is reset, which is exactly the invariance the callers already
>> assume.
>>
>> ...
>>
>> +	/*
>> +	 * Only a fully-online view is the complete cluster membership; if any
> 
> minor: the above sentence is hard to understand.
> 
Thanks for the feedback, I’ll simplify that sentence to make it clearer 
in the next patch revision.

>> +	if (!data_race(cpumask_equal(cpu_possible_mask, cpu_online_mask)))
> 
> AI review suggests using cpu_present_mask here:
> 
> 	https://sashiko.dev/#/patchset/20260807073612.3711269-1-Vishal.Badole@amd.com
> 
Good catch, I'll switch to cpu_present_mask in the next patch revision.