From nobody Thu Apr 2 12:06:12 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 21942373BF1 for ; Sun, 29 Mar 2026 17:40:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774806017; cv=none; b=WBJmjXbMdb5/tw+/bpByQ2qjTEwM3X51SH4dh2El/03ZyzzwcBdRi1/hHi06GyNslaR+Nzh5ZcdYTnV180ej/xIaNhlPs2nGaKK5BzzuYU1rGdSq6AJ4IeyYXJW83dChXLi6nDhBuVo+FCZcN7388rDnbwwXQ+r0Xs+FQ21RlLU= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774806017; c=relaxed/simple; bh=gdTMaxVewZevxekZoWFMV5QbPBw4+0c6ISVvV4ELeaw=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=O/axYXncsstb0YkLBq7I458pPBLinyafZtruw+kkThmgN6/eudA4d40XMh/EDqodXS4Np3bUMMKDrEA4u2xmKPUlW35008RlLVu/PDnE0RtpkdMlpZobXtXMnBwm2F54xpV1bXiaMlsQWR4R/gQVuV+4E3el7vX8NXsZRXWowcM= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=gT59E6Ux; arc=none smtp.client-ip=170.10.133.124 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.b="gT59E6Ux" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774806015; 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=23vwVawhhdaUlEZbOs+YhGbbQr0Na89/CEeqFQu0cCc=; b=gT59E6UxQyvHSCL7RrdoOmmxEdNDNA+r6/IyUWoHYbzmU173W51+6/zcx9h5NK9cKV7+ax Bk48ziwnLpbm450KkqDxnAJ5RaLcxw/AV2pnSpqW5WpxguMKZlHaVb9uuyM3xDQLPKZAb+ fWiR02eI9n58+6ikhnyxdnHJ+MCz9k0= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-318-RiNbVYAcN4iF8KNkaQFHMA-1; Sun, 29 Mar 2026 13:40:12 -0400 X-MC-Unique: RiNbVYAcN4iF8KNkaQFHMA-1 X-Mimecast-MFC-AGG-ID: RiNbVYAcN4iF8KNkaQFHMA_1774806010 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 78205180035C; Sun, 29 Mar 2026 17:40:10 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.80.75]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id 1CFBF19560B1; Sun, 29 Mar 2026 17:40:08 +0000 (UTC) From: Waiman Long To: Chen Ridong , Tejun Heo , Johannes Weiner , =?UTF-8?q?Michal=20Koutn=C3=BD?= Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Waiman Long Subject: [PATCH v2 1/3] cgroup/cpuset: Simplify setsched decision check in task iteration loop of cpuset_can_attach() Date: Sun, 29 Mar 2026 13:39:56 -0400 Message-ID: <20260329173958.2634925-2-longman@redhat.com> In-Reply-To: <20260329173958.2634925-1-longman@redhat.com> References: <20260329173958.2634925-1-longman@redhat.com> 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 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 Content-Type: text/plain; charset="utf-8" Centralize the check required to run security_task_setscheduler() in the task iteration loop of cpuset_can_attach() outside of the loop as it has no dependency on the characteristics of the tasks themselves. There is no functional change. Signed-off-by: Waiman Long --- kernel/cgroup/cpuset.c | 19 ++++++++++--------- 1 file changed, 10 insertions(+), 9 deletions(-) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index d21868455341..58c5b7b72cca 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -2988,7 +2988,7 @@ static int cpuset_can_attach(struct cgroup_taskset *t= set) struct cgroup_subsys_state *css; struct cpuset *cs, *oldcs; struct task_struct *task; - bool cpus_updated, mems_updated; + bool setsched_check; int ret; =20 /* used later by cpuset_attach() */ @@ -3003,20 +3003,21 @@ static int cpuset_can_attach(struct cgroup_taskset = *tset) if (ret) goto out_unlock; =20 - cpus_updated =3D !cpumask_equal(cs->effective_cpus, oldcs->effective_cpus= ); - mems_updated =3D !nodes_equal(cs->effective_mems, oldcs->effective_mems); + /* + * Skip rights over task setsched check in v2 when nothing changes, + * migration permission derives from hierarchy ownership in + * cgroup_procs_write_permission()). + */ + setsched_check =3D !cpuset_v2() || + !cpumask_equal(cs->effective_cpus, oldcs->effective_cpus) || + !nodes_equal(cs->effective_mems, oldcs->effective_mems); =20 cgroup_taskset_for_each(task, css, tset) { ret =3D task_can_attach(task); if (ret) goto out_unlock; =20 - /* - * Skip rights over task check in v2 when nothing changes, - * migration permission derives from hierarchy ownership in - * cgroup_procs_write_permission()). - */ - if (!cpuset_v2() || (cpus_updated || mems_updated)) { + if (setsched_check) { ret =3D security_task_setscheduler(task); if (ret) goto out_unlock; --=20 2.53.0 From nobody Thu Apr 2 12:06:12 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 1A9F5386561 for ; Sun, 29 Mar 2026 17:40:17 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.129.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774806019; cv=none; b=N5JlfA6Ci84mnw3pTbqnZGuUNA+W1VxhDitdAAbXgq7uZ7nK2iQ4UHdF00UMHV5OT2DRUPRXAvQSzKXuXstXb36so8RhwQ+USmKmxqTxl9UrT0OOUCrAGx8Zzpd2kUQmbeqh9EkKTe2l43yVYMFoyLgXkGXKFrM81AEX+dKEeu4= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774806019; c=relaxed/simple; bh=af5FS7aH6ycz5uhw1iiYzwZOSp7R9NC8fQ3SwU79FCg=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=ikSRtluKprghPRHVccxSibJAHTme/Ku2ewoZqir7Hs6GDt5UG3DpSvkj3KcDo3lb6gKfIMecMB1cTNchzjt5f+gkudKeU++G3A9ewx6SH5T4eSZAR8j7uPBD9TBbsgtDpmOX1cJWO9k/bO/6cvSxzPG9EUK3H7dUybi+w0XBf8Y= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=OmZ70iC0; arc=none smtp.client-ip=170.10.129.124 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.b="OmZ70iC0" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774806017; 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=NzNlRR4r4LS+8lLlmBQyOyMhjPBuedud46GINMqUfas=; b=OmZ70iC0ba5DZpvZuThrE5XhdPmvBQYDhIhmcpjyYcJRJ48+J74eaGdt+tt/SM4hbBRJrx 3T4HRYxD/apzeWafiQloLHdNI4HbtMz/MiiTODU5xwauyPgm68EfnxQK+iKmXpgHRu1uyn u/Nfd86Swd26VcRk95oAmogE1ICwkQc= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-335-JbtemHT-MPmiF57KR9ykLQ-1; Sun, 29 Mar 2026 13:40:13 -0400 X-MC-Unique: JbtemHT-MPmiF57KR9ykLQ-1 X-Mimecast-MFC-AGG-ID: JbtemHT-MPmiF57KR9ykLQ_1774806012 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 496081800283; Sun, 29 Mar 2026 17:40:12 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.80.75]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id E3D7219560AB; Sun, 29 Mar 2026 17:40:10 +0000 (UTC) From: Waiman Long To: Chen Ridong , Tejun Heo , Johannes Weiner , =?UTF-8?q?Michal=20Koutn=C3=BD?= Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Waiman Long Subject: [PATCH v2 2/3] cgroup/cpuset: Skip security check for hotplug induced v1 task migration Date: Sun, 29 Mar 2026 13:39:57 -0400 Message-ID: <20260329173958.2634925-3-longman@redhat.com> In-Reply-To: <20260329173958.2634925-1-longman@redhat.com> References: <20260329173958.2634925-1-longman@redhat.com> 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 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 Content-Type: text/plain; charset="utf-8" When a CPU hot removal causes a v1 cpuset to lose all its CPUs, the cpuset hotplug handler will schedule a work function to migrate tasks in that cpuset with no CPU to its ancestor to enable those tasks to continue running. If a strict security policy is in place, however, the task migration may fail when security_task_setscheduler() call in cpuset_can_attach() returns a -EACCESS error. That will mean that those tasks will have no CPU to run on. The system administrators will have to explicitly intervene to either add CPUs to that cpuset or move the tasks elsewhere if they are aware of it. This problem was found by a reported test failure in the LTP's cpuset_hotplug_test.sh. Fix this problem by treating this special case as an exception to skip the setsched security check as it is initated internally within the kernel itself instead of from user input. Do that by setting a new one-off CS_TASKS_OUT flag in the affected cpuset by the hotplug handler to allow cpuset_can_attach() to skip the security check. With that patch applied, the cpuset_hotplug_test.sh test can be run successfully without failure. Signed-off-by: Waiman Long --- kernel/cgroup/cpuset-internal.h | 1 + kernel/cgroup/cpuset-v1.c | 3 +++ kernel/cgroup/cpuset.c | 14 ++++++++++++++ 3 files changed, 18 insertions(+) diff --git a/kernel/cgroup/cpuset-internal.h b/kernel/cgroup/cpuset-interna= l.h index fd7d19842ded..75e2c20249ad 100644 --- a/kernel/cgroup/cpuset-internal.h +++ b/kernel/cgroup/cpuset-internal.h @@ -46,6 +46,7 @@ typedef enum { CS_SCHED_LOAD_BALANCE, CS_SPREAD_PAGE, CS_SPREAD_SLAB, + CS_TASKS_OUT, } cpuset_flagbits_t; =20 /* The various types of files and directories in a cpuset file system */ diff --git a/kernel/cgroup/cpuset-v1.c b/kernel/cgroup/cpuset-v1.c index 7308e9b02495..0c818edd0a1d 100644 --- a/kernel/cgroup/cpuset-v1.c +++ b/kernel/cgroup/cpuset-v1.c @@ -322,6 +322,9 @@ void cpuset1_hotplug_update_tasks(struct cpuset *cs, return; } =20 + /* Enable task removal without security check */ + set_bit(CS_TASKS_OUT, &cs->flags); + s->cs =3D cs; INIT_WORK(&s->work, cpuset_migrate_tasks_workfn); schedule_work(&s->work); diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 58c5b7b72cca..24d3ceef7991 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -3011,6 +3011,20 @@ static int cpuset_can_attach(struct cgroup_taskset *= tset) setsched_check =3D !cpuset_v2() || !cpumask_equal(cs->effective_cpus, oldcs->effective_cpus) || !nodes_equal(cs->effective_mems, oldcs->effective_mems); + /* + * Also check if task migration away from the old cpuset is allowed + * without security check. This bit should only be set by the hotplug + * handler when task migration from a child v1 cpuset to its ancestor + * is needed because there is no CPU left for the tasks to run on after + * a hot CPU removal. Clear the bit if set as it is one-off. Also + * doube-check the CPU emptiness of oldcs to be sure before clearing + * setsched_check. + */ + if (test_bit(CS_TASKS_OUT, &oldcs->flags)) { + if (cpumask_empty(oldcs->effective_cpus)) + setsched_check =3D false; + clear_bit(CS_TASKS_OUT, &oldcs->flags); + } =20 cgroup_taskset_for_each(task, css, tset) { ret =3D task_can_attach(task); --=20 2.53.0 From nobody Thu Apr 2 12:06:12 2026 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 55C3A3859FE for ; Sun, 29 Mar 2026 17:40:20 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774806021; cv=none; b=CrjiGhA64QkoqYaW/+CdSxATfx+xMuJ/v68F0rPuywNN4Wg47kiY/kppDkrfEBDgcO0lQw43COCLhMWwkPnYZ8FWXMesCwzYj2u54RMgVTnZsTtVu1oYSVc016dbDPQwBzerx7w7PgBfYgKeEWsQQrFJQsCn+pey3KA18IuEDsA= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1774806021; c=relaxed/simple; bh=w4W7UP+ZQEJmoexj9KDvhDM1dp1MOJyJFES4rZlqUY4=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=sB1IgtlQNlfY5I2YtWhReE8sxISZ3/PeAwdDr+SrXLFgK9RGs+J6D56+KK4bREWMFvhnZ2BqVemrxg36Fnfis/Ec6EveYmlWX0YZhq61ztPUAEOiDOhoXLl1RoSCkJvEaWvtJ35+SenKb0vL6QlJrHab4SpSZ2JwkNC9GlljUag= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=BPZE3uhP; arc=none smtp.client-ip=170.10.133.124 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.b="BPZE3uhP" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1774806019; 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=C0VwReO9RpU0du/pdr2lQ8z4eTzfYjZguiL25xTAtuE=; b=BPZE3uhPAhMkXGwz1bt3dMmvWFxApvjpAyU8zism/dIfDLuLX4KaEATlkjgM70wHdn+X3b GgwbuDS9uMT01uh29kNxSs5R3IdZd8372XWtzp9RnbWSInDJ6QorXqPrRqRnVMwaoMGr/r GvqU8McQffKozB+8opyuY54K/vvlnmQ= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-622-F7DUpheQPJ2t3IGUgqIbqQ-1; Sun, 29 Mar 2026 13:40:15 -0400 X-MC-Unique: F7DUpheQPJ2t3IGUgqIbqQ-1 X-Mimecast-MFC-AGG-ID: F7DUpheQPJ2t3IGUgqIbqQ_1774806014 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (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-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 1CFC118005B3; Sun, 29 Mar 2026 17:40:14 +0000 (UTC) Received: from llong-thinkpadp16vgen1.westford.csb (unknown [10.22.80.75]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTP id B65A319560AB; Sun, 29 Mar 2026 17:40:12 +0000 (UTC) From: Waiman Long To: Chen Ridong , Tejun Heo , Johannes Weiner , =?UTF-8?q?Michal=20Koutn=C3=BD?= Cc: cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Waiman Long Subject: [PATCH v2 3/3] cgroup/cpuset: Improve check for v1 task migration out of empty cpuset Date: Sun, 29 Mar 2026 13:39:58 -0400 Message-ID: <20260329173958.2634925-4-longman@redhat.com> In-Reply-To: <20260329173958.2634925-1-longman@redhat.com> References: <20260329173958.2634925-1-longman@redhat.com> 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 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 Content-Type: text/plain; charset="utf-8" With the "cpuset_v2_mode" mount option, cpuset v1 will emulate v2 in how it handles the management of CPUs. As a result, the effective_cpus can differ from cpus_allowed and an empty cpus_allowed will cause effective_cpus to inherit the value from its parent. Therefore task migration out of a cpuset with empty "cpuset.cpus" should no longer be needed in this case. The current code doesn't handle this particular case. Update the code to correctly detect that the cpuset has really no CPUs left by checking effective_cpus instead of cpus_allowed. Signed-off-by: Waiman Long --- kernel/cgroup/cpuset-v1.c | 10 ++++++---- 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/kernel/cgroup/cpuset-v1.c b/kernel/cgroup/cpuset-v1.c index 0c818edd0a1d..9855de37d011 100644 --- a/kernel/cgroup/cpuset-v1.c +++ b/kernel/cgroup/cpuset-v1.c @@ -261,7 +261,7 @@ static void remove_tasks_in_empty_cpuset(struct cpuset = *cs) * has online cpus, so can't be empty). */ parent =3D parent_cs(cs); - while (cpumask_empty(parent->cpus_allowed) || + while (cpumask_empty(parent->effective_cpus) || nodes_empty(parent->mems_allowed)) parent =3D parent_cs(parent); =20 @@ -297,14 +297,16 @@ void cpuset1_hotplug_update_tasks(struct cpuset *cs, =20 /* * Don't call cpuset_update_tasks_cpumask() if the cpuset becomes empty, - * as the tasks will be migrated to an ancestor. + * as the tasks will be migrated to an ancestor. If cpuset_v2_mode mount + * option is used, effective_cpus can differ from cpus_allowed. So + * checking effective_cpus is more accurate for determining emptiness. */ - if (cpus_updated && !cpumask_empty(cs->cpus_allowed)) + if (cpus_updated && !cpumask_empty(cs->effective_cpus)) cpuset_update_tasks_cpumask(cs, new_cpus); if (mems_updated && !nodes_empty(cs->mems_allowed)) cpuset_update_tasks_nodemask(cs); =20 - is_empty =3D cpumask_empty(cs->cpus_allowed) || + is_empty =3D cpumask_empty(cs->effective_cpus) || nodes_empty(cs->mems_allowed); =20 /* --=20 2.53.0