From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (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 A57F52E06EA for ; Mon, 4 May 2026 07:48:39 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777880921; cv=none; b=QvWc5rYMUZKaZ51Cl/pxLA52V5Z33PDAWIOmreja3F40OLF3c0DUsI/U1j0bkSMMF/5GLvBg1UXDQFYWSas4GLYTZlJUZm8f/7EVcX7S6SkyiHyKrvlyfME/6vZPdMbHfp7VuL7xOXVsGeymy6w32hvYKwB1KDkk5cjHVqeyiSQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1777880921; c=relaxed/simple; bh=o8OS3gfWCPenJx55XOIO5Ca6rXmRnpCW9+iDJpnaWHk=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=mkRDIEhcTrkcff0gqHUrXVqZpHyjr3pAeRhRk5dUEYMi7ncEE9V325vmT2aJ2LHzE0t0Uwe4gewm2H+C+Tw/DEBJbVbtkovr0SQ+hCC474ukIOVbbQD+vMXDYFNsSGX1pM1LqzIvy8xRtCZPSdbJc+WfW43ws81hCiKKz7vBEuM= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=m8vYQ1Rf; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="m8vYQ1Rf" DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=G7g6GzHSNE7v7B0HuCmP1nHbj5u4TUyRz4hD1W+wvIM=; b=m8vYQ1Rfl1RRLdIu5MPwkHmIbC Zw2H5xdVYZC0mF08CPqWNuCmPX2vgE6ktKOqyYZ3KCmo9B8cqNrXqoAJ5+SUhHnJfqctVDmWcZyJT esEqP1owt42jKd865JU6NWxIj+fZ5HwxWemLfrRCn1hAkvhpKyDtZnEOJwamo867g2iaOqR73m80u gpt8Hg1gz14x5Qnih7OjI0c9tmUiM8vH4dQA1oiETfs9a+kdT9fXkqSNBsy3B5sRuHLKlLcF0W4tP 34nhazxZPoqiGuoJjqE1TRhH17SVOWG/ldr+kFtN1pj66Mg22tYGtAsHtaSh/+A1j2CgdedJ7AmB8 i2XkaksQ==; Received: from 2001-1c00-8d85-4b00-266e-96ff-fe07-7dcc.cable.dynamic.v6.ziggo.nl ([2001:1c00:8d85:4b00:266e:96ff:fe07:7dcc] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.98.2 #2 (Red Hat Linux)) id 1wJo2Y-00000000X4k-35Ut; Mon, 04 May 2026 07:48:30 +0000 Received: by noisy.programming.kicks-ass.net (Postfix, from userid 1000) id 215E03013A0; Mon, 04 May 2026 09:48:30 +0200 (CEST) Date: Mon, 4 May 2026 09:48:30 +0200 From: Peter Zijlstra To: w15303746062@163.com Cc: tglx@kernel.org, mingo@redhat.com, bp@alien8.de, dave.hansen@linux.intel.com, x86@kernel.org, hpa@zytor.com, linux-kernel@vger.kernel.org Subject: Re: [BUG] x86/smpboot: WARN_ON in set_cpu_sibling_map triggered by numa=fake=2 Message-ID: <20260504074830.GM3126523@noisy.programming.kicks-ass.net> References: <20260429034125.37368-1-w15303746062@163.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: <20260429034125.37368-1-w15303746062@163.com> You forgot to Cc lkml. On Wed, Apr 29, 2026 at 11:41:25AM +0800, w15303746062@163.com wrote: > Hi x86 maintainers, > > While fuzzing the v7.0 kernel, I encountered a persistent WARNING in > `set_cpu_sibling_map()` during boot when using the `numa=fake=2` > command-line parameter. > > The issue appears to be a logic gap in the topology consistency check. > When `numa=fake=N` is used, it artificially divides a single physical > package into multiple software NUMA nodes. However, the existing check > in `set_cpu_sibling_map()` does not account for this fake NUMA state: > > if (match_pkg(c, o) && !topology_same_node(c, o)) > WARN_ON_ONCE(topology_num_nodes_per_package() == 1); > > Since `numa=fake` forces `!topology_same_node(c, o)` to be true for > CPUs on the same package, the WARN_ON_ONCE is falsely triggered. With > `panic_on_warn=1` enabled in many fuzzing and testing environments, > this leads to an early boot panic. *groan*, so ideally we'd just rip out the whole fake numa stuff entirely, and let people use VMs to fake topology in a consistent manner. I'm assuming something like so helps? diff --git a/arch/x86/kernel/smpboot.c b/arch/x86/kernel/smpboot.c index 294a8ea60298..2447b0317f7b 100644 --- a/arch/x86/kernel/smpboot.c +++ b/arch/x86/kernel/smpboot.c @@ -468,6 +468,8 @@ static int x86_cluster_flags(void) } #endif +static bool x86_has_fake_numa = false; + static struct sched_domain_topology_level x86_topology[] = { SDTL_INIT(tl_smt_mask, cpu_smt_flags, SMT), #ifdef CONFIG_SCHED_CLUSTER @@ -489,7 +491,7 @@ static void __init build_sched_topology(void) * PKG domain since the NUMA domains will auto-magically create the * right spanning domains based on the SLIT. */ - if (topology_num_nodes_per_package() > 1) { + if (topology_num_nodes_per_package() > 1 || x86_has_fake_numa) { unsigned int pkgdom = ARRAY_SIZE(x86_topology) - 2; memset(&x86_topology[pkgdom], 0, sizeof(x86_topology[pkgdom])); @@ -662,6 +664,13 @@ int arch_sched_node_distance(int from, int to) topology_num_nodes_per_package() < 3) return d; + /* + * XXX someone needs to figure out what, if anything can be + * done here. + */ + if (WARN_ON_ONCE(x86_has_fake_numa)) + return d; + /* * Handle SNC-3 asymmetries. */ @@ -694,8 +703,10 @@ void set_cpu_sibling_map(int cpu) for_each_cpu(i, cpu_sibling_setup_mask) { o = &cpu_data(i); - if (match_pkg(c, o) && !topology_same_node(c, o)) - WARN_ON_ONCE(topology_num_nodes_per_package() == 1); + if (match_pkg(c, o) && !topology_same_node(c, o)) { + if (topology_num_nodes_per_package() == 1) + x86_has_fake_numa = true; + } if ((i == cpu) || (has_smt && match_smt(c, o))) link_mask(topology_sibling_cpumask, cpu, i);