From nobody Thu Sep 24 13:37:21 2026 Received: from mta0.migadu.com (out-156.mta0.migadu.com [91.218.175.156]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id DF4454119EE for ; Wed, 23 Sep 2026 08:56:40 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=91.218.175.156 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790153802; cv=none; b=OemG7PIvOq+6y/FeRwMBgX0BqOoiZ4FGsTigjhkJ+caK5tY5DU/rnLi2CsLZxz7XDPGQTCEX4N09Y52yXdMRRLTY606qV1eWE4yBHLmi31UDcKuBoFmFEObHz2hv4cix7yesc+y6DtRYhc0soS5bskrqPysJ+XdF7Qc6rKKbWuQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1790153802; c=relaxed/simple; bh=dnPq4pRHlT6hpC3lghdvKVIgRaHtyf+n6DAJtS+2gSk=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=Y1Mb3nHNd0+nSh8tT4RCpgI7NcNNMymFlthr9iENkgZuNKAB/QBnRkUTqdJ1TF6EH9aH8kr1DlZ00LRZ4xmo+wPTRHNQ2T9y634sJpKAIyQ4QGXp6W4euWISUULJUvlp/dvyU3jorpibBgSPr5PRyTa+r+mCXLD38Sg3Qzg/39I= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=oXZF0OB+; arc=none smtp.client-ip=91.218.175.156 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="oXZF0OB+" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=dnPq4pRHlT6hpC3lghdvKVIgRaHtyf+n6DAJtS+2gSk=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1790153798; v=1; x=1790758598; b=oXZF0OB+RmD1ab//9L5cZkloiO/n5jwMqKIhXAmLw8oQMSx01KHbWJKNDs3pi0AcXov9BFlj DZcCPXAFG/tHpnopAoOfAv31RtBK6NhraJo+kf8gJLaQKaM1TK2YNCc8d8CPq45bhGcRoqkh8Q8 Ut4CcAiIJ7FE6fxYkZC00BjU= X-Envelope-To: linux-kernel@vger.kernel.org Received: by smtp.migadu.com with ESMTPS id a3c32f82d4955334; Wed, 23 Sep 2026 08:56:37 +0000 X-Mizu-Trace-ID: a3c32f82d4955334 X-Migadu-Flow: FLOW_OUT From: Guopeng Zhang To: Waiman Long , Ridong Chen Cc: Tejun Heo , Johannes Weiner , =?UTF-8?q?Michal=20Koutn=C3=BD?= , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Guopeng Zhang Subject: [PATCH] cgroup/cpuset: Cancel CPU transfer when housekeeping check fails Date: Wed, 23 Sep 2026 16:56:24 +0800 Message-ID: <20260923085624.172022-1-guopeng.zhang@linux.dev> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" From: Guopeng Zhang Widening an isolated child partition to include the last kernel-noise housekeeping CPU invalidates the partition, but the CPU transfer computed before the housekeeping check is still applied: WARNING: kernel/cgroup/cpuset.c:1315 at partition_xcpus_add+0x61/0x70, = CPU#1: sh/1052 Call Trace: update_parent_effective_cpumask+0x320/0xa30 cpuset_write_resmask+0x1e6/0x7c0 ---[ end trace 0000000000000000 ]--- This can be reproduced on a 32-CPU system booted with nohz_full=3D1: cd /sys/fs/cgroup echo +cpuset > cgroup.subtree_control mkdir A B C C/child echo 0 > A/cpuset.cpus echo isolated > A/cpuset.cpus.partition echo 4-31 > B/cpuset.cpus echo isolated > B/cpuset.cpus.partition echo +cpuset > C/cgroup.subtree_control echo 2-3 > C/cpuset.cpus echo root > C/cpuset.cpus.partition echo 3 > C/child/cpuset.cpus echo isolated > C/child/cpuset.cpus.partition echo 2-3 > C/child/cpuset.cpus The last write returns 0 and leaves the hierarchy in this state: root (cpuset.cpus.effective=3D1) | +-- A (isolated): cpuset.cpus=3D0 | cpuset.cpus.effective=3D0 +-- B (isolated): cpuset.cpus=3D4-31 | cpuset.cpus.effective=3D4-31 \-- C (root): cpuset.cpus=3D2-3 | cpuset.cpus.effective=3D \-- C/child (invalid isolated): cpuset.cpus=3D2-3 cpuset.cpus.effective=3D Before the last write, C owns CPU 2 and C/child owns CPU 3. The last write changes C/child's CPU mask from 3 to 2-3, which would transfer CPU 2 from C to C/child. The housekeeping check invalidates C/child, but delmask still contains CPU 2 while addmask is empty. partition_xcpus_add() therefore removes CPU 2 from C and warns because the new partition state is invalid. CPU 3 is not returned when C/child is invalidated, leaving both CPUs unavailable to any valid partition. Handle PERR_HKEEPING like PERR_NOCPUS: cancel the pending transfer and rebuild addmask from the CPUs currently held by the child. This leaves CPU 2 in C and returns CPU 3 to C. Fixes: 103b08709e8a ("cgroup/cpuset: Fail if isolated and nohz_full don't l= eave any housekeeping") Signed-off-by: Guopeng Zhang --- kernel/cgroup/cpuset.c | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 753aa65afcd7..a4ead0d3c872 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -1929,6 +1929,17 @@ static int update_parent_effective_cpumask(struct cp= uset *cs, int cmd, /* Adding to parent means adding isolated CPUs */ !isolated_cpus_can_update(tmp->addmask, tmp->delmask)) part_error =3D PERR_HKEEPING; + if (part_error =3D=3D PERR_HKEEPING) { + /* + * Fall back to returning all the granted + * CPUs to the parent instead of applying + * the pending change. + */ + deleting =3D false; + adding =3D cpumask_and(tmp->addmask, + cs->effective_xcpus, + parent->effective_xcpus); + } } =20 /* --=20 2.43.0