From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1792639068; b=JxKF5G+blP2Uf2GGb1oJNHwEsLXFFCjNi6nqSZu2hC6NaH9zdLZRxyaZetN2aq0olefA guXamozFfDHB8HKDd8KCOLP4hl9/LKJedt6SAvadM2KYY4Vpf03qdxunOpO8PYxBHlGcU MD/ElHRcObygHK9i5Mk0BjqmDNzHLuyB3QFxXOFwS1ndaY0MIdZvYnJEmPo23w6GCufIc 1M7fqS2sTzwgEmrAXjLdexyP3NqJHZrutrHoF0+mVCK8XMw5zeoHEKi+w53o9wg9v7aJM KPr/1vdeS0Oz6u3AR1HXAzaTBMcUXGDlAMxjkjXzQPiyR9gUVJie+GfuffsrfdBO6eQ== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1792639068; h=DMARC-Filter:DKIM-Signature:Received:X-MC-Unique: X-Mimecast-MFC-AGG-ID:Received:Received:From:To:Cc:Subject:Date: Message-ID:In-Reply-To:References:MIME-Version: Content-Transfer-Encoding:X-Scanned-By; bh=xbb0rBkkCa7muoGBUUDLmxu4mhfIGLsWVgJ2P59sJ6s=; b=wJuLcVWWk53zF2Q3kLzHQA1ZUlmtE8zWPfKOs4/BkIJV5zImm74RWZFIIksfDcNCpDEi qCulbgirw7mvSYKLz5+m2IgpQpzhbmBZ4C46oKu/kmM+c6mKS8FmADxeFMNTCOraNTeY0 dQAr+Sryo8phfbeeWk+lHko5nuJpwruBXZCoI8aBJDGnRiuj5po4Fx3jsdKxwkJBWNM5Y 0oul/QSZkKDNzMbcipZA0UK8bQsSyxVqQId2VKVQmKzf1Fa8aNnXbMLN95DcNP2rYRfJd lczN8bGrP10/AY7YT6HM4mQGpc90vBAOtV96/Z6jA/nWRS9I2JLlsXbohfcNGKv6LqQ== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b="jVdu/KSm"; arc=none smtp.remote-ip=170.10.133.124 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id BACB560A5BC6 for ; Thu, 22 Oct 2026 03:17:47 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org BACB560A5BC6 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=jVdu/KSm DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1792639067; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=xbb0rBkkCa7muoGBUUDLmxu4mhfIGLsWVgJ2P59sJ6s=; b=jVdu/KSmVyPbwa3h7Y0scOeGuyjZzGo6ghNYu/rrJvlgMXGbCmEk+8orIpIqBuR3Iqdhhk uWdg4HNJrU6xfaXd9EtwLsxj6PScvuhbZ6vL3HDVECRxPOn/0i7MEXRLvub487ABjq6ZNx uoFUwXdABcQEi+pCPLMsuV+zAxAVbo4= Received: from mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-22-ddoCJCcWMtaP-fXMUTKQFg-1; Wed, 21 Oct 2026 23:17:38 -0400 X-MC-Unique: ddoCJCcWMtaP-fXMUTKQFg-1 X-Mimecast-MFC-AGG-ID: ddoCJCcWMtaP-fXMUTKQFg_1792639056 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mx-prod-mc-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 5C2A41955EB1; Thu, 22 Oct 2026 03:17:35 +0000 (UTC) Received: from llong-thinkpadp16vgen1.rmtusnh.csb (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 5407918000A3; Thu, 22 Oct 2026 03:17:33 +0000 (UTC) From: Waiman Long To: Ridong Chen , Tejun Heo , Johannes Weiner , =?UTF-8?q?Michal=20Koutn=C3=BD?= , Shuah Khan Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org, Guopeng Zhang , Waiman Long , Guopeng Zhang Subject: [PATCH-next 6/6] cgroup/cpuset: Prevent recursive call of remote_cpus_update() via update_cpumasks_hier() Date: Wed, 21 Oct 2026 23:16:43 -0400 Message-ID: <20261022031643.1351877-7-longman@redhat.com> In-Reply-To: <20261022031643.1351877-1-longman@redhat.com> References: <20261022031643.1351877-1-longman@redhat.com> X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 Guopeng reports that changing the cpumask of a remote partition root may set the effective_cpus of the top_cpuset incorrectly. It is due to the following call sequence: update_cpumask() -> partition_cpus_change() -> remote_cpus_update() -> update_sibling_cpumasks() -> update_cpumasks_hier() -> remote_cpus_update() The second remote_cpus_update() call passes in the cs->effective_xcpus instead of the trialcs->effective_xcpus of the first remote_cpus_update() call. As a result, the second call can revert what has been done in the first call leading to incorrect effective_cpus of the top_cpuset as well as subpartitions_cpus. Fix that by adding a new remote_partition_updating flag into the cpuset structure to indicate that a remote partition is being updated and update_cpumasks_hier() should skip the whole subtree as update_cpumask() or update_exclusive_cpumask() which calls partition_cpus_change() will eventually calls update_cpumasks_hier() for that subtree anyway. This new flag is currently set only in remote_cpus_update() to prevent recursive call of remote_cpus_update() on the same cpuset. A test case is added to test_cpuset_prs.sh to verify this change. Reported-by: Guopeng Zhang Link: https://lore.kernel.org/lkml/20261010075947.333549-2-guopeng.zhang@linux.dev Fixes: f62a5d39368e ("cgroup/cpuset: Remove remote_partition_check() & make update_cpumasks_hier() handle remote partition") Signed-off-by: Waiman Long --- kernel/cgroup/cpuset-internal.h | 5 +++++ kernel/cgroup/cpuset.c | 13 +++++++++---- tools/testing/selftests/cgroup/test_cpuset_prs.sh | 1 + 3 files changed, 15 insertions(+), 4 deletions(-) diff --git a/kernel/cgroup/cpuset-internal.h b/kernel/cgroup/cpuset-internal.h index 2e44dc8634dc..1ba94ffaff9d 100644 --- a/kernel/cgroup/cpuset-internal.h +++ b/kernel/cgroup/cpuset-internal.h @@ -161,6 +161,11 @@ struct cpuset { */ bool remote_partition; + /* + * Set to true when a remote partition is undergoing update. + */ + bool remote_partition_updating; + /* * number of SCHED_DEADLINE tasks attached to this cpuset, so that we * know when to rebuild associated root domain bandwidth information. diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 6e1bef12f86d..952b31246d62 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -1736,6 +1736,7 @@ static void remote_cpus_update(struct cpuset *cs, struct cpumask *xcpus, goto invalidate; } + cs->remote_partition_updating = true; spin_lock_irq(&callback_lock); if (adding) partition_xcpus_add(prs, NULL, tmp->addmask); @@ -1757,6 +1758,7 @@ static void remote_cpus_update(struct cpuset *cs, struct cpumask *xcpus, */ cpuset_update_tasks_cpumask(&top_cpuset, tmp->new_cpus); update_sibling_cpumasks(&top_cpuset, NULL, tmp); + cs->remote_partition_updating = false; return; invalidate: @@ -2208,16 +2210,19 @@ static void update_cpumasks_hier(struct cpuset *cs, struct tmpmasks *tmp, old_prs = new_prs = cp->partition_root_state; /* - * For child remote partition root (!= cs), we need to call - * remote_cpus_update() if effective_xcpus will be changed. - * Otherwise, we can skip the whole subtree. + * For a child remote partition with remote_partition_updating + * set, we can skip the whole subtree as the this function will + * be called eventually. We can also skip the subtree if the + * effective_xcpus isn't going to be changed. Otherwise, we + * will have to call remote_cpus_update(). * * remote_cpus_update() will reuse tmp->new_cpus only after * its value is being processed. */ if (remote && (cp != cs)) { compute_excpus(cp, tmp->new_cpus); - if (cpumask_equal(cp->effective_xcpus, tmp->new_cpus)) { + if (cp->remote_partition_updating || + cpumask_equal(cp->effective_xcpus, tmp->new_cpus)) { pos_css = css_rightmost_descendant(pos_css); continue; } diff --git a/tools/testing/selftests/cgroup/test_cpuset_prs.sh b/tools/testing/selftests/cgroup/test_cpuset_prs.sh index 5bc144836bdf..19c50819065c 100755 --- a/tools/testing/selftests/cgroup/test_cpuset_prs.sh +++ b/tools/testing/selftests/cgroup/test_cpuset_prs.sh @@ -347,6 +347,7 @@ TEST_MATRIX=( " C0-3 C1-3 C2-3 C4 X2-3 X2-3 X2-3:P2 P2:C4-5 0 A3:2-3|B1:4-5 A3:P2|B1:P2 2-5" " C4:X0-3 X1-3 X2-3 . . P2 . . 0 A1:4|A2:1-3|A3:1-3 A2:P2 1-3" " C4:X0-3 X1-3 X2-3 . . . P2 . 0 A1:4|A2:4|A3:2-3 A3:P2 2-3" + " CX1-6 C1-4:P1 . C4-5 . C1-3 . . 0 A1:4-6|A2:1-3|B1:4-5 A2:P1" # Nested remote/local partition tests " C0-3 C1-3 C2-3 C4-5 X2-3 X2-3:P1 P2 P1 0 A1:0-1|A2:|A3:2-3|B1:4-5 \ -- 2.55.0