From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from galois.linutronix.de (Galois.linutronix.de [193.142.43.55]) (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 DE2134C98 for ; Sat, 22 Nov 2025 15:36:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=193.142.43.55 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763825792; cv=none; b=PUFKChu6zFB671VZJpWvyF3tkc5ssHnkf/T2nSrBMytLRNIqA8VEYhXGX3y7W8nqi5Jph2fWjQLblNbVTC6p6pb+8OSopAGIyxq2XkcUNJyM+rivB3nwd+OA5xdR0+Px0uU0wIS8EhIRKCuCCI0bW1jt6KSjogosBFZRCWAr3tU= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1763825792; c=relaxed/simple; bh=WiVtkNDOy/9y0Hn2fspypeE3vPL8vcHiJURBaf9QeiA=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=pZA6pcCZLy8mWSYvZibdzloDt3veb+rLy+pPbvkO23EvH7y5HphUWNJvJuPKTS5IxqeJ0ZrwHzitToT7th7/8GzILHsZVL8OIS0MFvEd4YaWniXm5DAAkDnXCr7qDD1stvD1Vn992VCO2A+dmCJA+jJrgul0kXnY9ZmCWp2TPM4= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de; spf=pass smtp.mailfrom=linutronix.de; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=Cw6/MD1Z; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b=w6fUSnEr; arc=none smtp.client-ip=193.142.43.55 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linutronix.de Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linutronix.de Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="Cw6/MD1Z"; dkim=permerror (0-bit key) header.d=linutronix.de header.i=@linutronix.de header.b="w6fUSnEr" From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1763825789; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MIBMSZgnpEf4lVYfSycZAxtT172J8j31G+2veH5fzcU=; b=Cw6/MD1ZRcQ24ToZfdGp9nJdCXl3M8RHnzgqr3Gndb8kzQhw1zFlKQdKxY1+u7mGPzbf+r l5rWjw49r50/ib5D/Cs5aHqq9lz3pdECn7qZFbjKimaJ98iiNfe2v1ecGpTGpGbwGSvVE+ iku07eO48ymBHLQyh3JKaT99RnXbxek6fRWO2rNT1IoNbOp4hKYnnpks4QUJxJiiDMBpRf cqk3TutpGJrxoSAkOxfskbfcRcm22K/+NeVc1ImrMUfeEEJZi8tfH//x3zvzwBRL2uegp8 aoI1ZipliXXoVN6PVBJ2mNtoLkTrt+Zn67ZNU2LuEe5CtCEvVi+LeW6oV/bOEw== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1763825789; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MIBMSZgnpEf4lVYfSycZAxtT172J8j31G+2veH5fzcU=; b=w6fUSnEr0/Oa7dxyJgNTAhIvNncvLZSnAfrtQqQTXnQvAMZjf1Hk8XFihrls4BVa1rAYe8 Jfmo7cUv8DMctaAA== To: Marek Szyprowski , LKML Cc: Peter Zijlstra , Gabriele Monaco , Mathieu Desnoyers , Michael Jeanson , Jens Axboe , "Paul E. McKenney" , "Gautham R. Shenoy" , Florian Weimer , Tim Chen , Yury Norov , Shrikanth Hegde , Nathan Chancellor Subject: Re: [patch V5 09/20] cpumask: Cache num_possible_cpus() In-Reply-To: <89c7106e-a431-443a-9527-3d5fbce77fe1@samsung.com> References: <20251119171016.815482037@linutronix.de> <20251119172549.578653738@linutronix.de> <89c7106e-a431-443a-9527-3d5fbce77fe1@samsung.com> Date: Sat, 22 Nov 2025 16:36:28 +0100 Message-ID: <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=utf-8 Content-Transfer-Encoding: quoted-printable 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=C2=A0c= an I=20 > help debugging it. Can you test the fix below please? 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=3Dn 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@sa= msung.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 =3D {CPU_BITS_ALL}; +unsigned int __num_possible_cpus __ro_after_init =3D 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); =20 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); =20 -unsigned int __num_possible_cpus __ro_after_init =3D NR_CPUS; -EXPORT_SYMBOL(__num_possible_cpus); - void init_cpu_present(const struct cpumask *src) { cpumask_copy(&__cpu_present_mask, src);