From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mgamail.intel.com (mgamail.intel.com [198.175.65.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8C00D4854F0 for ; Thu, 13 Aug 2026 16:51:15 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.175.65.11 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786639878; cv=none; b=IqlzshJgvK5M3ZTEks8gYvSVCboAOv63i2x4aYR+Kpq1onROjtwy8X6GxYAPNX7XX5kbVMudPa0gjYV+8pjB56N3mXjrK98zvRgn039+h2AugRBv+HVCvORe+m/5G80eUd1G0sy33RzNbW2Ob62JzilNEgZ1kmhMwHKAS8Lck28= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786639878; c=relaxed/simple; bh=07Et+Ei2gQGjlaX8LaiOd7ybsQcObkLJcyNW5cTzvXM=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=lp/UwHDUfg/d+Vl3wCnIFFMVtNAzPJ4Q6qaCtKB5jYzyZhJdWmuNL6NV6+CQBtyyZFwrsStGkCZhm3qk16iLRO0AsGLwaKrBRxOyNJanHcxx8OwS7PyTrj5ERkJA1U18lJXXXvAiinOtQ4dhCPia2bCVDxwUfAuUhpTVGc88vQU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com; spf=pass smtp.mailfrom=linux.intel.com; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b=Zdr2StqJ; arc=none smtp.client-ip=198.175.65.11 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="Zdr2StqJ" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1786639876; x=1818175876; h=message-id:subject:from:to:cc:date:in-reply-to: references:content-transfer-encoding:mime-version; bh=07Et+Ei2gQGjlaX8LaiOd7ybsQcObkLJcyNW5cTzvXM=; b=Zdr2StqJhz3OuIKR6v0dFCVFjfzJ2MqV6IEENm0T+WssrVidivoUhBD8 9RdmiEf/YZNmKz5FBY6OoGrmkXxLwdHJZrwXWZeN+sFrjZD7O3UbGxJZx iuF3FC/GvI+mWUItnhM2gAJY9c0iIKkUoBK3/LmMd8JBscKEhMR81+f1A rXBryF1iQP/iYYIN8xEt25H/5S7tWUGRLjq4zZtlQhEbvMJ3gCKQcX3Uo pquDrN06SpVTs1z4X68KPig41su/uHO9DGbOoj6rUjnbWxnRhXGs5OPrh 4lzizipmM5pBS3XqBK8Enq7cqP75TpmpkkVF3rxoxPIZ28bY0sCOe+MhL w==; X-CSE-ConnectionGUID: 14hxyUzLTKa+L01pGwqtvA== X-CSE-MsgGUID: cz366+jYT4K/cH8eW1FDmQ== X-IronPort-AV: E=McAfee;i="6800,10657,11874"; a="97567143" X-IronPort-AV: E=Sophos;i="6.25,221,1779174000"; d="scan'208";a="97567143" Received: from orviesa008.jf.intel.com ([10.64.159.148]) by orvoesa103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Aug 2026 09:51:15 -0700 X-CSE-ConnectionGUID: vH1UWmdFSfyN3DQxPJnRpg== X-CSE-MsgGUID: 2kD4nkYvTAW431/A3lj8AA== X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.25,221,1779174000"; d="scan'208";a="263542077" Received: from unknown (HELO [10.241.243.185]) ([10.241.243.185]) by orviesa008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 13 Aug 2026 09:51:15 -0700 Message-ID: Subject: Re: [PATCH] sched/topology: Add a cpus_read_lock to partition_sched_domains() From: Tim Chen To: Chen Yu 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 Date: Thu, 13 Aug 2026 09:51:14 -0700 In-Reply-To: References: <20260812095800.gl06ANul@linutronix.de> <8c36c744-973a-4e33-a72a-eed0cffc05da@intel.com> <42b0af4923217f39bae45ec4c0eba9599ecdbf5c.camel@linux.intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.58.1 (3.58.1-1.fc43) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Thu, 2026-08-13 at 10:24 +0800, Chen Yu wrote: > On Wed, Aug 12, 2026 at 11:05:24AM -0700, Tim Chen wrote: > > > > void partition_sched_domains(int ndoms_new, cpumask_var_t doms_ne= w[], > > > > 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(); > > >=20 > > > Thanks for taking a look at this issue. I found that there is a comme= nt=20 > > > around > > > partition_sched_domains() says: "Call with hotplug lock held" > > > Not sure if the caller of partition_sched_domains() rather than=20 > > > partition_sched_domains() > > > should grab the cpuhotplug lock? I guess the issue is triggered when > > > CONFIG_CPUSETS=3Dn, in this case rebuild_sched_domains() will not gra= b > > > cpuhotplug lock, should we add guard(cpus_read_lock) in=20 > > > rebuild_sched_domains() > > > instead? > >=20 > > When CONFIG_CPUSETS=3Dn, rebuild_sched_domains() is stubbed to > >=20 > > static inline void rebuild_sched_domains(void) > > { > > partition_sched_domains(1, NULL, NULL); > > } > >=20 > > without cpus_read_lock. Are you suggesting adding the lock > > here? We do acquire the lock for CONFIG_CPUSETS=3Dy. > >=20 >=20 > Yes, I think so. > =20 > > 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. > >=20 >=20 > cpuset_reset_sched_domains() is invoked by cpuset_cpu_inactive()=20 > 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(). >=20 > So it should be ok to not take hotplug lock in cpuset_reset_sched_domains= (). Yes, likewise cpuset_update_active_cpus() that uses partition_sched_domains= (1, NULL, NULL) is called from cpu-hotplug path with proper lock, we are good there too. Tim