public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Waiman Long <longman@redhat.com>
Cc: "Johannes Weiner" <hannes@cmpxchg.org>,
	"Michal Koutný" <mkoutny@suse.com>,
	"Shuah Khan" <shuah@kernel.org>,
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org
Subject: Re: [PATCH 01/10] cgroup/cpuset: Fix race between newly created partition and dying one
Date: Mon, 31 Mar 2025 13:13:16 -1000	[thread overview]
Message-ID: <Z-shjD2OwHJPI0vG@slm.duckdns.org> (raw)
In-Reply-To: <20250330215248.3620801-2-longman@redhat.com>

Hello,

On Sun, Mar 30, 2025 at 05:52:39PM -0400, Waiman Long wrote:
...
> One possible way to fix this is to iterate the dying cpusets as well and
> avoid using the exclusive CPUs in those dying cpusets. However, this
> can still cause random partition creation failures or other anomalies
> due to racing. A better way to fix this race is to reset the partition
> state at the moment when a cpuset is being killed.

I'm not a big fan of adding another method call in the destruction path.
css_offline() is where the kill can be seen from all CPUs and notified to
the controller and I'm not sure why bringing it sooner would be necessary to
close the race window. Can't the creation side drain the cgroups that are
going down if the asynchronous part is a problem? e.g. We already have
cgroup_lock_and_drain_offline() which isn't the most scalable thing but
partition operations aren't very frequent, right? And if that's a problem,
there should be a way to make it reasonably quicker.

Thanks.

-- 
tejun

  reply	other threads:[~2025-03-31 23:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-30 21:52 [PATCH 00/10] cgroup/cpuset: Miscellaneous partition bug fixes and enhancements Waiman Long
2025-03-30 21:52 ` [PATCH 01/10] cgroup/cpuset: Fix race between newly created partition and dying one Waiman Long
2025-03-31 23:13   ` Tejun Heo [this message]
2025-04-01  3:12     ` Waiman Long
2025-04-01 19:59       ` Tejun Heo
2025-04-01 20:41         ` Waiman Long
2025-04-01 20:56           ` Waiman Long
2025-04-02  7:49   ` Tejun Heo
2025-04-03 13:34     ` Michal Koutný
2025-04-03 16:15       ` Tejun Heo
2025-03-30 21:52 ` [PATCH 02/10] cgroup/cpuset: Fix incorrect isolated_cpus update in update_parent_effective_cpumask() Waiman Long
2025-03-30 21:52 ` [PATCH 03/10] cgroup/cpuset: Fix error handling in remote_partition_disable() Waiman Long
2025-03-30 21:52 ` [PATCH 04/10] cgroup/cpuset: Remove remote_partition_check() & make update_cpumasks_hier() handle remote partition Waiman Long
2025-03-30 21:52 ` [PATCH 05/10] cgroup/cpuset: Don't allow creation of local partition over a remote one Waiman Long
2025-04-03 13:33   ` Michal Koutný
2025-04-03 13:48     ` Waiman Long
2025-03-30 21:52 ` [PATCH 06/10] cgroup/cpuset: Code cleanup and comment update Waiman Long
2025-03-30 21:52 ` [PATCH 07/10] cgroup/cpuset: Remove unneeded goto in sched_partition_write() and rename it Waiman Long
2025-04-03 13:33   ` Michal Koutný
2025-04-03 13:49     ` Waiman Long
2025-03-30 21:52 ` [PATCH 08/10] selftest/cgroup: Update test_cpuset_prs.sh to use | as effective CPUs and state separator Waiman Long
2025-03-30 21:52 ` [PATCH 09/10] selftest/cgroup: Clean up and restructure test_cpuset_prs.sh Waiman Long
2025-03-30 21:52 ` [PATCH 10/10] selftest/cgroup: Add a remote partition transition test to test_cpuset_prs.sh Waiman Long
2025-03-31 23:28   ` Tejun Heo

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=Z-shjD2OwHJPI0vG@slm.duckdns.org \
    --to=tj@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=mkoutny@suse.com \
    --cc=shuah@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox