From nobody Mon Feb 9 16:45:54 2026 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id E3BAFC74A5B for ; Wed, 29 Mar 2023 16:12:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229735AbjC2QMY (ORCPT ); Wed, 29 Mar 2023 12:12:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51404 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229699AbjC2QMN (ORCPT ); Wed, 29 Mar 2023 12:12:13 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0691C1BEF for ; Wed, 29 Mar 2023 09:10:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680106203; 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=GdNce1OaiYHGRSBqnplg9LW3FvXe3v9Sj0lSo9jGEts=; b=JTiLIjKBXwQhXakkcluuQn0T3glnernO2eppPPuSYPtG3vfydgxWHbrEyreFK9K75DJ45g qlmuPdv4tQ7eaQedEJQYQKEp/vWobWvNGQWKRY/gjM/lKUlcBnIi/7DXndrEb7Y+rSDz3v 5cKVA97rTxod78ah0KMllxP+4RWS4+Q= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-70-8Bgv-gTXP4SCXryUdo8LqA-1; Wed, 29 Mar 2023 12:03:14 -0400 X-MC-Unique: 8Bgv-gTXP4SCXryUdo8LqA-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 433FB3C0D85F; Wed, 29 Mar 2023 16:03:13 +0000 (UTC) Received: from llong.com (unknown [10.22.34.224]) by smtp.corp.redhat.com (Postfix) with ESMTP id B00C0202701F; Wed, 29 Mar 2023 16:03:11 +0000 (UTC) From: Waiman Long To: Juri Lelli , Peter Zijlstra , Ingo Molnar , Qais Yousef , Tejun Heo , Zefan Li , Johannes Weiner , Hao Luo Cc: linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Dietmar Eggemann , Steven Rostedt , luca.abeni@santannapisa.it, claudio@evidence.eu.com, tommaso.cucinotta@santannapisa.it, bristot@redhat.com, mathieu.poirier@linaro.org, Vincent Guittot , Wei Wang , Rick Yiu , Quentin Perret , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Sudeep Holla , Waiman Long Subject: [PATCH 6/7] cgroup/cpuset: Protect DL BW data against parallel cpuset_attach() Date: Wed, 29 Mar 2023 12:02:40 -0400 Message-Id: <20230329160240.2093277-1-longman@redhat.com> In-Reply-To: <20230329125558.255239-1-juri.lelli@redhat.com> References: <20230329125558.255239-1-juri.lelli@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Type: text/plain; charset="utf-8" It is possible to have parallel attach operations to the same cpuset in progress. To avoid possible corruption of single set of DL BW data in the cpuset structure, we have to disallow parallel attach operations if DL tasks are present. Attach operations can still proceed in parallel as long as no DL tasks are involved. This patch also stores the CPU where DL BW is allocated and free that BW back to the same CPU in case cpuset_can_attach() is called. Signed-off-by: Waiman Long --- kernel/cgroup/cpuset.c | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c index 05c0a1255218..555a6b1a2b76 100644 --- a/kernel/cgroup/cpuset.c +++ b/kernel/cgroup/cpuset.c @@ -199,6 +199,7 @@ struct cpuset { */ int nr_deadline_tasks; int nr_migrate_dl_tasks; + int dl_bw_cpu; u64 sum_migrate_dl_bw; =20 /* Invalid partition error code, not lock protected */ @@ -2502,6 +2503,16 @@ static int cpuset_can_attach(struct cgroup_taskset *= tset) if (cpumask_empty(cs->effective_cpus)) goto out_unlock; =20 + /* + * If there is another parallel attach operations in progress for + * the same cpuset, the single set of DL data there may get + * incorrectly overwritten. So parallel operations are not allowed + * if DL tasks are present. + */ + ret =3D -EBUSY; + if (cs->nr_migrate_dl_tasks) + goto out_unlock; + cgroup_taskset_for_each(task, css, tset) { ret =3D task_can_attach(task); if (ret) @@ -2511,6 +2522,9 @@ static int cpuset_can_attach(struct cgroup_taskset *t= set) goto out_unlock; =20 if (dl_task(task)) { + if (cs->attach_in_progress) + goto out_unlock; + cs->nr_migrate_dl_tasks++; cs->sum_migrate_dl_bw +=3D task->dl.dl_bw; } @@ -2533,6 +2547,7 @@ static int cpuset_can_attach(struct cgroup_taskset *t= set) reset_migrate_dl_data(cs); goto out_unlock; } + cs->dl_bw_cpu =3D cpu; } =20 out_succes: @@ -2559,9 +2574,7 @@ static void cpuset_cancel_attach(struct cgroup_taskse= t *tset) cs->attach_in_progress--; =20 if (cs->nr_migrate_dl_tasks) { - int cpu =3D cpumask_any(cs->effective_cpus); - - dl_bw_free(cpu, cs->sum_migrate_dl_bw); + dl_bw_free(cs->dl_bw_cpu, cs->sum_migrate_dl_bw); reset_migrate_dl_data(cs); } =20 --=20 2.31.1