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=1794240580; b=GMJvO8vUVKSfqfqyFJWAjx3YO8Tx3jKh6bxj9T5ed0vlVZRCCFpX7FlWmulW2rDWL2xn +wostEKNz+65RNeOSdMI8SgvqIUrYqgaYgGL6ZIf4KSkYJARcy6mxe9nVF76DJHimlb5m m2NhNg0f0B6kv+LWWHqaNojaxSIAVb5U/CTVkqpt8ybxRC8tfxoJWDH9cXoHp4hgjzIo7 8+WIxBAT4btvWWiec+CeJg6HRjlsQ2oz8Ox7J+ShTA+YbuHeaLuwuTHRFPMZPmsqJE1yY mP1mfCV9QF61ONXqkXjGD/3kGDZFcPk3W3Xx261Q9ZDhG2ci8E9xz+fCVWXkGVlYPEg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794240580; 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=CilHB2QJxes/RbxW8DdIdUjgRZu+jKegkhox90qTSy4=; b=C0N6VlrdKddLj3ZPIfzJQ9iCTeHltgx0rR4gNJ7OnxgcEiA6nEqX28VNg+Cknhc1qbzo 3bZdAs7PX6pyotDHa49nVqcjblc1VEpLRm4e0NY18L0zoqdtigCF6qbslkHv7QivXvPzs 3rDsaw6lPqj5fc2BF9cbwMgqX53VOx4M0LbNOEYTx4cdPUas++FGo1iBWzQUGp5TKu9ly 3NYAjVuatcTcPRAQV6fvtgpNuLFzzPVAEbfNmTYFHyXhKQ9+Ps4wieuet9IZ9465OpYJU CdU2RURaVeUsb2NOP+SGSuXdsC2b2wY8tzz1vNiQG40uRruJaz+DCggAo5aRdseAjkg== 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=JI81lmJF; 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 46885606A331 for ; Mon, 9 Nov 2026 16:09:40 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.4.2 smtp.subspace.kernel.org 46885606A331 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) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=JI81lmJF DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1794240579; 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=CilHB2QJxes/RbxW8DdIdUjgRZu+jKegkhox90qTSy4=; b=JI81lmJF+X4dGdSsaJIYjOuqKhMD/qW5LTEJ/G5/IzsUvsSXaz5lAVoYFKDEbs1LL/RCwU ANfVvmUyoZ/5Z7jDuQ9cXikTmLSJ00i1yNk0zJaOaeqbwdFxWY0iWYKbIbjBSL3FRVSf5h SWBaIJHq2a0X9NgaRZiGhDiyLo9ORYk= Received: from mx-prod-mc-01.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-224-IH9CHWuyM7at2hEPJ05lAA-1; Mon, 09 Nov 2026 11:09:33 -0500 X-MC-Unique: IH9CHWuyM7at2hEPJ05lAA-1 X-Mimecast-MFC-AGG-ID: IH9CHWuyM7at2hEPJ05lAA_1794240572 Received: from mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.95]) (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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 773B91955EB1; Mon, 9 Nov 2026 16:09:31 +0000 (UTC) Received: from llong-thinkpadp16vgen1.redhat.corp (headnet04.pony-001.prod.iad2.dc.redhat.com [10.2.32.116]) by mx-prod-int-10.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id D16D326C; Mon, 9 Nov 2026 16:09:29 +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 , Sashiko Subject: [PATCH 2/5] cgroup/cpuset: Fix incorrect partition invalidation logic in cpuset_hotplug_update_tasks() Date: Mon, 9 Nov 2026 11:09:09 -0500 Message-ID: <20261109160912.1369897-3-longman@redhat.com> In-Reply-To: <20261109160912.1369897-1-longman@redhat.com> References: <20261109160912.1369897-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.6 on 10.30.177.95 When most of the active CPUs of a system are allocated to sub-partitions below the top_cpuset partition, it is possible that a CPU offline operation may remove the last active CPU in the top_cpuset partition. When that really happens, cpuset_handle_hotplug() will clear the subpartitions_cpus to make sure active CPUs are present in the top partition and let the other sub-partitions get invalidated and then competes for their exclusive CPUs again. In cpuset_hotplug_update_tasks(), the current code use "cpumask_empty(subpartitions_cpus)" to determine if that partition should be invalidated. That is fine if there is only one sub-partition. As reported by sashiko that when there are more than one sub-partitions and the first sub-partition will get invalidated and then it will try to acquire the exclusive CPUs and become valid again. When this happens, the subpartitions_cpus will no longer be empty. The remaining sub-partitions will assume their exclusive CPUs are safe and proceed as normal. As a result, active CPUs owned by those sub-partitions remain in both top_cpuset.effective_cpus and the sub-partitions' effective_cpus while missing from subpartitions_cpus, breaking partition CPU exclusivity and triggering WARN_ON_ONCE() in generate_sched_domains() and remote_partition_disable(). Fix that by checking if the sub-partitions' effective_xcpus are subset of subpartitions_cpus to determine if they should be invalidated. Fixes: 0c7f293efc87 ("cgroup/cpuset: Add cpuset.cpus.exclusive.effective for v2") Reported-by: Sashiko Link: https://sashiko.dev/#/bug/linux-bf69cd3c-833a-4599-a1f9-8dd9e044cd7c Signed-off-by: Waiman Long --- kernel/cgroup/cpuset.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 40e7d33847f7..e8169b739454 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -4002,9 +4002,9 @@ static void cpuset_hotplug_update_tasks(struct cpuset *cs, struct tmpmasks *tmp) if (!tmp || !cs->partition_root_state) goto update_tasks; - if (is_remote_partition(cs) && (cpumask_empty(subpartitions_cpus) || - (cpumask_empty(&new_cpus) && - partition_is_populated(cs, NULL)))) { + if (is_remote_partition(cs) && + (!cpumask_subset(cs->effective_xcpus, subpartitions_cpus) || + (cpumask_empty(&new_cpus) && partition_is_populated(cs, NULL)))) { WRITE_ONCE(cs->prs_err, PERR_HOTPLUG); remote_partition_disable(cs, tmp); compute_effective_cpumask(&new_cpus, cs, parent); @@ -4021,7 +4021,7 @@ static void cpuset_hotplug_update_tasks(struct cpuset *cs, struct tmpmasks *tmp) if (is_local_partition(cs) && (!is_partition_valid(parent) || tasks_nocpu_error(parent, cs, &new_cpus) || - cpumask_empty(subpartitions_cpus))) + !cpumask_subset(cs->effective_xcpus, subpartitions_cpus))) partcmd = partcmd_invalidate; /* * On the other hand, an invalid partition root may be transitioned -- 2.56.0