From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mta1.migadu.com (out-29.mta1.migadu.com [95.215.58.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1CD331D5ADE for ; Thu, 13 Aug 2026 02:25:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=95.215.58.29 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786587909; cv=none; b=sT4sHQ6/CLUcPoNw7ITfr3j1ZzA75Zwpzlx8nWNGaX81Kn0PvvuRChmJljlREBmiZYYXdTrE+ovmAULmw9k/kIfdUoUxPhnmjAcFBZSMRl/iGkz8mZxz6ybHlXxREYXU/flPwZ7PuV2Fmd+UfdZOccxaPas1NfryJQOwL1M/mx4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786587909; c=relaxed/simple; bh=gFSKPazGo1dAlSyijIKXq5lGONI+3YiD3KiWRirA6Mk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=K71gke8JOnR28ti9z/KXC+7tsirAlXfE4sDHteSq/EVNpN8lxiSAXE6dQ8JJ+BFcVd5gY8amKuUCO4ni/bxivkyfzUxdn7CXmhYcDxlZHGzgCYKvfpEKdkvcKxpj9YLESBWTMP2YoB7ZUX7QiPPDf5JSOJIZc0GWm32PjK6gLo8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev; spf=pass smtp.mailfrom=linux.dev; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b=AUkZdgNw; arc=none smtp.client-ip=95.215.58.29 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.dev Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.dev Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=linux.dev header.i=@linux.dev header.b="AUkZdgNw" X-Envelope-To: linux-kernel@vger.kernel.org DKIM-Signature: a=rsa-sha256; bh=gFSKPazGo1dAlSyijIKXq5lGONI+3YiD3KiWRirA6Mk=; c=simple/simple; d=linux.dev; h=from:to:subject:date:message-id:mime-version:content-type; s=key1; t=1786587905; v=1; x=1787192705; b=AUkZdgNwa3nNCM7RotYkhya9LH+80w7D9Tm0iePcDHBMTIwQ/16cS3/PdpX+5Ofk6iHMIsi2 e9QbYRrj4YsBumaPSm19r2dRwEubYoJoLnx/H/XCIODGpRGYuiAaCj16CEEpQvA46XYvf5pUhxx 0aCsaSd9owDFSjLOjE5sCNXU= X-Envelope-To: linux-kernel@vger.kernel.org Received: from three-body (240e:398:91:37f0:2e7e:cdf5:29fd:7e8) by smtp.migadu.com with ESMTPS id 40e5be1dff7c01c9; Thu, 13 Aug 2026 02:24:54 +0000 X-Migadu-Flow: FLOW_OUT Date: Thu, 13 Aug 2026 10:24:41 +0800 From: Chen Yu To: Tim Chen Cc: "Chen, Yu C" , Sebastian Andrzej Siewior , Ben Segall , Dietmar Eggemann , Ingo Molnar , Juri Lelli , K Prateek Nayak , Mel Gorman , Peter Zijlstra , Steven Rostedt , Valentin Schneider , Vincent Guittot , linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched/topology: Add a cpus_read_lock to partition_sched_domains() Message-ID: References: <20260812095800.gl06ANul@linutronix.de> <8c36c744-973a-4e33-a72a-eed0cffc05da@intel.com> <42b0af4923217f39bae45ec4c0eba9599ecdbf5c.camel@linux.intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 > >