From: Waiman Long <longman@redhat.com>
To: Aaron Tomlin <atomlin@atomlin.com>
Cc: Dietmar Eggemann <dietmar.eggemann@arm.com>,
tj@kernel.org, hannes@cmpxchg.org, mkoutny@suse.com,
chenridong@huaweicloud.com, neelx@suse.com,
cgroups@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] cpuset: Fix multi-source deadline task accounting and bandwidth bypass
Date: Thu, 14 May 2026 00:26:35 -0400 [thread overview]
Message-ID: <bda91fbe-e14f-45b1-8c61-27f16122bcc1@redhat.com> (raw)
In-Reply-To: <djbtucfusnpngys2nritqsi7stjq243zchel45ahfgaruba7el@4rtk534mfq4j>
On 5/13/26 7:39 PM, Aaron Tomlin wrote:
> On Wed, May 13, 2026 at 07:19:18PM -0400, Waiman Long wrote:
>> Multiple source or destination cpusets in task migration can only happens
>> when the cpuset controller is enabled or disabled in a cgroup subtree. If
>> there are DL tasks in 2 or more child cgroups, enabling or disabling of the
>> cpuset controller for those child cgroups may lead to incorrect DL task
>> accounting. This patch will probably fix the DL accounting aspect. However,
>> there are also other issues unrelated to DL tasks that need to be addressed
>> as well. So this patch is incomplete in this regard. I am working on a patch
>> series to address these issues. Hopefully I can send it out in a day or 2.
>>
> Hi Longman,
>
> Acknowledged.
>
> Also, the Sashiko AI review reported: "TOCTOU race on dl_task(task) during
> rollback causes state corruption."
>
> A concurrent sched_setscheduler() could alter the scheduling class of a
> task between the initial pass and a rollback. This assertion seems valid to
> me. Currently, neither cgroup_mutex or cpuset_mutex prevents scheduling
> class changes.
>
> Should I let you handle this too?
No, you can handle it if you want. I am more familiar with the cpuset
code, but scheduler is much more complex. I don't think I have enough
understanding of the code to handle it correctly.
Cheers,
Longman
prev parent reply other threads:[~2026-05-14 4:26 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-12 1:03 [PATCH] cpuset: Fix multi-source deadline task accounting and bandwidth bypass Aaron Tomlin
2026-05-13 16:22 ` Dietmar Eggemann
2026-05-13 23:09 ` Aaron Tomlin
2026-05-13 23:19 ` Waiman Long
2026-05-13 23:39 ` Aaron Tomlin
2026-05-14 4:26 ` Waiman Long [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=bda91fbe-e14f-45b1-8c61-27f16122bcc1@redhat.com \
--to=longman@redhat.com \
--cc=atomlin@atomlin.com \
--cc=cgroups@vger.kernel.org \
--cc=chenridong@huaweicloud.com \
--cc=dietmar.eggemann@arm.com \
--cc=hannes@cmpxchg.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mkoutny@suse.com \
--cc=neelx@suse.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.