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 84C8D2C21E7 for ; Sat, 22 Nov 2025 19:09:50 +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=1763838590; cv=none; b=JxjvmKQFrSL31YLI2o0Mqh1hcawjFRNGDH5FnGVv6LbYKgYzKpop0b/rE7huC/KpuDXCM5TBsYL+Rbqs37cfdQb/DvyqdEmBxwfoE0dr6U6FxYrxGsPSpW+4u3ks/qT3/nynE5qo6ag+/OZFCgubZQj8msXzLHISHVtwKLEpCLU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763838590; c=relaxed/simple; bh=pJucV4HXj3vekLOrHK26MgyX8+H849BItYQnWpvCO/o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=Ys4ROiJ7Cxl0cjGdvInfHv+7lETcHtLTF3zfErZycsX79KKWzQ42B0hN5OQl67eYl25IczPJ6gvFv3DmgRy/5OyCLpfa719TNnc4bodblToOlc5bPqgHfAxYUIX6aLOBnInLzUkWtsWNZ37dUxCySfqpn+QWHOKJCCOlUvr7ei0= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=o1QumWm8; 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="o1QumWm8" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 1DD63C116D0; Sat, 22 Nov 2025 19:09:50 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1763838590; bh=pJucV4HXj3vekLOrHK26MgyX8+H849BItYQnWpvCO/o=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To:From; b=o1QumWm8Nmg8K+zGmPNHlJxNwB09kyLTeBn/jFH1T8yX5qq9B7K3XlXi9qvGpp7U4 yHL2sNB1qj81qMMpYzSElv+LLzfjpMLI6Kku7NSOknUIN8BoiBuSyw4lOcpE77f3NH VIK2broS8BgflNw2RzjPslX2OMNA8VqFScXqz2TF8pI8//IQbnSSHNHfPt676rV0iU I54SUp4Legd6WB+cNF8I999x75Vz9OyqFWBYAfS3v6t+qLu7B5NwKXoqBXvxwnbnOf 0nNDabJYTFXUO39vB4Q26+huO5uO6cvBmZZRjiVPu2+1W6oc2NcklRcjdqbvtlNv/L 09Zp73T2HnQEw== Received: by paulmck-ThinkPad-P17-Gen-1.home (Postfix, from userid 1000) id 933A7CE0CFD; Sat, 22 Nov 2025 11:09:49 -0800 (PST) Date: Sat, 22 Nov 2025 11:09:49 -0800 From: "Paul E. McKenney" To: Marek Szyprowski Cc: Thomas Gleixner , LKML , Peter Zijlstra , Gabriele Monaco , Mathieu Desnoyers , Michael Jeanson , Jens Axboe , "Gautham R. Shenoy" , Florian Weimer , Tim Chen , Yury Norov , Shrikanth Hegde , Nathan Chancellor Subject: Re: [patch V5 09/20] cpumask: Cache num_possible_cpus() Message-ID: <74f47d05-e7bd-4b6e-8e2f-9558c20422ed@paulmck-laptop> Reply-To: paulmck@kernel.org References: <20251119171016.815482037@linutronix.de> <20251119172549.578653738@linutronix.de> <89c7106e-a431-443a-9527-3d5fbce77fe1@samsung.com> <87zf8ehyf7.ffs@tglx> 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=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Sat, Nov 22, 2025 at 05:24:22PM +0100, Marek Szyprowski wrote: > > On 22.11.2025 16:36, Thomas Gleixner wrote: > > On Fri, Nov 21 2025 at 23:56, Marek Szyprowski wrote: > >> Reverting it on top of linux-next fixes the issue. Let me know how can I > >> help debugging it. > > Can you test the fix below please? > > This fixes the observed issue. Thanks! > > Tested-by: Marek Szyprowski And I clearly should have read ahead, but thank you for the quick fix! Tested-by: Paul E. McKenney > > Thanks, > > > > tglx > > --- > > Subject: cpu: Initialize __num_possible_cpus correctly > > From: Thomas Gleixner > > Date: Sat, 22 Nov 2025 16:19:18 +0100 > > > > The variable to cache the number of possible CPUs is initialized to NR_CPUS > > at build time, but that's only correct when cpu_possible_mask is > > initialized with CPU_BITS_ALL. That's only the case on PARISC. > > > > On x86 and some other architectures this does not matter because they > > initialize cpu_possible_mask via init_cpu_possible() which does a proper > > weight calculation. Though on architectures which do not, this results > > in a completely wrong cached value 'NR_CPUS + actual possible CPUs'. > > > > Initialize it correctly to 0 when CONFIG_INIT_ALL_POSSIBLE=n and move the > > NR_CPUS initialization into the PARISC specific section. > > > > Fixes: d0f23ccf6ba9 ("cpumask: Cache num_possible_cpus()") > > Reported-by: Marek Szyprowski > > Reported-by: Nathan Chancellor > > Signed-off-by: Thomas Gleixner > > Closes: https://lore.kernel.org/all/89c7106e-a431-443a-9527-3d5fbce77fe1@samsung.com > > Closes: https://lore.kernel.org/all/20251122002755.GA2682494@ax162 > > --- > > kernel/cpu.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > > --- a/kernel/cpu.c > > +++ b/kernel/cpu.c > > @@ -3085,10 +3085,13 @@ EXPORT_SYMBOL(cpu_all_bits); > > #ifdef CONFIG_INIT_ALL_POSSIBLE > > struct cpumask __cpu_possible_mask __ro_after_init > > = {CPU_BITS_ALL}; > > +unsigned int __num_possible_cpus __ro_after_init = NR_CPUS; > > #else > > struct cpumask __cpu_possible_mask __ro_after_init; > > +unsigned int __num_possible_cpus __ro_after_init; > > #endif > > EXPORT_SYMBOL(__cpu_possible_mask); > > +EXPORT_SYMBOL(__num_possible_cpus); > > > > struct cpumask __cpu_online_mask __read_mostly; > > EXPORT_SYMBOL(__cpu_online_mask); > > @@ -3108,9 +3111,6 @@ EXPORT_SYMBOL(__cpu_dying_mask); > > atomic_t __num_online_cpus __read_mostly; > > EXPORT_SYMBOL(__num_online_cpus); > > > > -unsigned int __num_possible_cpus __ro_after_init = NR_CPUS; > > -EXPORT_SYMBOL(__num_possible_cpus); > > - > > void init_cpu_present(const struct cpumask *src) > > { > > cpumask_copy(&__cpu_present_mask, src); > > > Best regards > -- > Marek Szyprowski, PhD > Samsung R&D Institute Poland >