From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 D879D34F46C; Fri, 31 Oct 2025 16:08:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761926893; cv=none; b=p+yYkcKVqoV8FNRNoUrm167b133MfLytUbu+JacqnA9h94m5jyuxAxnRe+Tb5Jf5gpcXjzF9hY9L+Cq98LdvsPJe+VOgkydK4MwwJRgaxw6SSfSAFTfeNGOyVQvWyy3wCREhOKHSSnh7Ge7eUHqzdR41i3vf9RfLJs79RhFWq4c= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1761926893; c=relaxed/simple; bh=DBnRWCc9yOikTyJAePQMQXl8JnrzRu+fPN1hD2Ld8qU=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=eIRAAy3Cv3mCN0owTp9W7KpkNHE4M9QWuKYpJsfjNNGLN/mxGC507nhKV7iHJADgz4jVdALLlBQtcVc9etJPLt6xC015TAx9uehTdnNOSGcAinmRUswvAKQ0hcIR84Br7oi0H8yA+D137fPjosoTfDDNGsX4HEv5H2ErYtMrT7o= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=lNm3q3Fx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="lNm3q3Fx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id CDA40C4CEE7; Fri, 31 Oct 2025 16:08:11 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1761926892; bh=DBnRWCc9yOikTyJAePQMQXl8JnrzRu+fPN1hD2Ld8qU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lNm3q3FxkqsL5QWMXLypsadCbVDHoS7srbuL3umgOILAgP2CmodbUjbmVgoYLqLve gqW5tz1EPBizlAZk5MqElD4DQfIHAxzmtN19JFglozpQKcQGBxYMl7yLPgL06f0Alc Wmr5T7iw805pUJEirQ0gG/+y+Tb8PrWnxbGm6rEfbp7xc7L8cnr1zQFwXjAnhR1hBH leAVv9GH6W28+5E2FEe+8vxpWiPWLa7dvgRWsbm9oHb0ZrOKO2qaDT1p5UMDci9pYi 2qfoSEzL1lmFVYHaphzP0WGPUKmYmpipLpz2ALLuOYx0tXFwTP1Ngxt7pTzWQPBIkK d4ltC1wGy9Gzg== Date: Fri, 31 Oct 2025 17:08:09 +0100 From: Frederic Weisbecker To: Chen Ridong Cc: LKML , Michal =?iso-8859-1?Q?Koutn=FD?= , Andrew Morton , Bjorn Helgaas , Catalin Marinas , Danilo Krummrich , "David S . Miller" , Eric Dumazet , Gabriele Monaco , Greg Kroah-Hartman , Ingo Molnar , Jakub Kicinski , Jens Axboe , Johannes Weiner , Lai Jiangshan , Marco Crivellari , Michal Hocko , Muchun Song , Paolo Abeni , Peter Zijlstra , Phil Auld , "Rafael J . Wysocki" , Roman Gushchin , Shakeel Butt , Simon Horman , Tejun Heo , Thomas Gleixner , Vlastimil Babka , Waiman Long , Will Deacon , cgroups@vger.kernel.org, linux-arm-kernel@lists.infradead.org, linux-block@vger.kernel.org, linux-mm@kvack.org, linux-pci@vger.kernel.org, netdev@vger.kernel.org Subject: Re: [PATCH 11/33] cpuset: Provide lockdep check for cpuset lock held Message-ID: References: <20251013203146.10162-1-frederic@kernel.org> <20251013203146.10162-12-frederic@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Le Tue, Oct 14, 2025 at 09:29:25PM +0800, Chen Ridong a écrit : > > > On 2025/10/14 4:31, Frederic Weisbecker wrote: > > cpuset modifies partitions, including isolated, while holding the cpuset > > mutex. > > > > This means that holding the cpuset mutex is safe to synchronize against > > housekeeping cpumask changes. > > > > Provide a lockdep check to validate that. > > > > Signed-off-by: Frederic Weisbecker > > --- > > include/linux/cpuset.h | 2 ++ > > kernel/cgroup/cpuset.c | 7 +++++++ > > 2 files changed, 9 insertions(+) > > > > diff --git a/include/linux/cpuset.h b/include/linux/cpuset.h > > index 2ddb256187b5..051d36fec578 100644 > > --- a/include/linux/cpuset.h > > +++ b/include/linux/cpuset.h > > @@ -18,6 +18,8 @@ > > #include > > #include > > > > +extern bool lockdep_is_cpuset_held(void); > > + > > #ifdef CONFIG_CPUSETS > > > > /* > > diff --git a/kernel/cgroup/cpuset.c b/kernel/cgroup/cpuset.c > > index 8595f1eadf23..aa1ac7bcf2ea 100644 > > --- a/kernel/cgroup/cpuset.c > > +++ b/kernel/cgroup/cpuset.c > > @@ -279,6 +279,13 @@ void cpuset_full_unlock(void) > > cpus_read_unlock(); > > } > > > > +#ifdef CONFIG_LOCKDEP > > +bool lockdep_is_cpuset_held(void) > > +{ > > + return lockdep_is_held(&cpuset_mutex); > > +} > > +#endif > > + > > static DEFINE_SPINLOCK(callback_lock); > > > > void cpuset_callback_lock_irq(void) > > Is the lockdep_is_cpuset_held function actually being used? > If CONFIG_LOCKDEP is disabled, compilation would fail with an "undefined reference to > lockdep_is_cpuset_held" error. Although counter-intuitive, this is how the lockdep_is_held() functions family do work. This allows this kind of trick: if (IS_ENABLED(CONFIG_LOCKDEP)) WARN_ON_ONCE(!lockdep_is_held(&some_lock)) This works during the compilation because the prototype of lockdep_is_held() is declared. And since the IS_ENABLED() is resolved during compilation as well, the conditional code is wiped out and therefore not linked. As a result the linker doesn't even look for the definition of lockdep_is_held() and we don't need to define an off case that would return a wrong assumption. Thanks. -- Frederic Weisbecker SUSE Labs