All of lore.kernel.org
 help / color / mirror / Atom feed
From: Chen Yu <chen.yu@linux.dev>
To: Tim Chen <tim.c.chen@linux.intel.com>
Cc: "Chen, Yu C" <yu.c.chen@intel.com>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	Ben Segall <bsegall@google.com>,
	Dietmar Eggemann <dietmar.eggemann@arm.com>,
	Ingo Molnar <mingo@redhat.com>,
	Juri Lelli <juri.lelli@redhat.com>,
	K Prateek Nayak <kprateek.nayak@amd.com>,
	Mel Gorman <mgorman@suse.de>,
	Peter Zijlstra <peterz@infradead.org>,
	Steven Rostedt <rostedt@goodmis.org>,
	Valentin Schneider <vschneid@redhat.com>,
	Vincent Guittot <vincent.guittot@linaro.org>,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sched/topology: Add a cpus_read_lock to partition_sched_domains()
Date: Thu, 13 Aug 2026 10:24:41 +0800	[thread overview]
Message-ID: <an0q6TrALX9tIzpn@three-body> (raw)
In-Reply-To: <42b0af4923217f39bae45ec4c0eba9599ecdbf5c.camel@linux.intel.com>

On Wed, Aug 12, 2026 at 11:05:24AM -0700, Tim Chen wrote:
> > >   void partition_sched_domains(int ndoms_new, cpumask_var_t doms_new[],
> > >   			     struct sched_domain_attr *dattr_new)
> > >   {
> > > +	guard(cpus_read_lock)();
> > >   	sched_domains_mutex_lock();
> > >   	partition_sched_domains_locked(ndoms_new, doms_new, dattr_new);
> > >   	sched_domains_mutex_unlock();
> > 
> > Thanks for taking a look at this issue. I found that there is a comment 
> > around
> > partition_sched_domains() says: "Call with hotplug lock held"
> > Not sure if the caller of partition_sched_domains() rather than 
> > partition_sched_domains()
> > should grab the cpuhotplug lock? I guess the issue is triggered when
> > CONFIG_CPUSETS=n, in this case rebuild_sched_domains() will not grab
> > cpuhotplug lock, should we add guard(cpus_read_lock) in 
> > rebuild_sched_domains()
> > instead?
> 
> When CONFIG_CPUSETS=n, rebuild_sched_domains() is stubbed to
> 
> static inline void rebuild_sched_domains(void)
> {
>         partition_sched_domains(1, NULL, NULL);
> }
> 
> without cpus_read_lock.  Are you suggesting adding the lock
> here?  We do acquire the lock for CONFIG_CPUSETS=y.
>

Yes, I think so.
 
> If we do follow this convention, cpuset_reset_sched_domains()
> and cpuset_reset_sched_domains() also stubbed to
> partition_sched_domains(1, NULL, NULL);
> Probably should add cpus_read_lock there too for consistency.
>

cpuset_reset_sched_domains() is invoked by cpuset_cpu_inactive() 
and via CPU-hotplug callback, and in cpuhp_thread_fun:
static void cpuhp_thread_fun(unsigned int cpu)
{
	lockdep_acquire_cpus_lock(); <--- lockdep
	call_back();
}
and according to the comments:
"
/*
 * The BP holds the hotplug lock, but we're now running on the AP,
 * ensure that anybody asserting the lock is held, will actually find
 * it so.
 */
"
it pretend that AP has grabed the lock on behalf of the BP in
_cpu_down(), which has grabed the cpu-hotplug write lock:
cpus_write_lock().

So it should be ok to not take hotplug lock in cpuset_reset_sched_domains().

thanks,
Chenyu
 
 
> Tim
> 
> > 
> > thanks,
> > Chenyu
> > 

      reply	other threads:[~2026-08-13  2:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-12  9:58 [PATCH] sched/topology: Add a cpus_read_lock to partition_sched_domains() Sebastian Andrzej Siewior
2026-08-12 12:54 ` Chen, Yu C
2026-08-12 18:05   ` Tim Chen
2026-08-13  2:24     ` Chen Yu [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=an0q6TrALX9tIzpn@three-body \
    --to=chen.yu@linux.dev \
    --cc=bigeasy@linutronix.de \
    --cc=bsegall@google.com \
    --cc=dietmar.eggemann@arm.com \
    --cc=juri.lelli@redhat.com \
    --cc=kprateek.nayak@amd.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgorman@suse.de \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=rostedt@goodmis.org \
    --cc=tim.c.chen@linux.intel.com \
    --cc=vincent.guittot@linaro.org \
    --cc=vschneid@redhat.com \
    --cc=yu.c.chen@intel.com \
    /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.