linux-kernel - Re: [PATCH v3] ACPI/PPTT: Check total CPU numbers when a CPU can't be found in PPTT table

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <aW7dnymr6yXFRTDp@U-2FWC9VHC-2323.local>
Date: Tue, 20 Jan 2026 09:42:55 +0800
From: Feng Tang <feng.tang@...ux.alibaba.com>
To: Sudeep Holla <sudeep.holla@....com>
Cc: "Rafael J . Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
	Jeremy Linton <jeremy.linton@....com>,
	Hanjun Guo <guohanjun@...wei.com>,
	James Morse <james.morse@....com>,
	Joanthan Cameron <Jonathan.Cameron@...wei.com>,
	linux-acpi@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3] ACPI/PPTT: Check total CPU numbers when a CPU can't
 be found in PPTT table

On Fri, Jan 16, 2026 at 01:52:37PM +0000, Sudeep Holla wrote:
> On Fri, Jan 16, 2026 at 03:29:43PM +0800, Feng Tang wrote:
> > There was a bug that kernel printed error message:
> > " ACPI PPTT: PPTT table found, but unable to locate core 1 (1)"
> > and later on the kernel met issues when building up scheduler domain.
> > 
> > Debug showed the kernel actually brought up all 8 CPUs successfully
> > (MADT and other table worked fine), while the PPTT table was broken
> > as it only had 4 CPUs in total.
> > 
> > Add check for number of CPU of PPTT table against system CPU number,
> > and warn if they are not equal, to help debugging similar issues.
> > 
> > Suggested-by: Sudeep Holla <sudeep.holla@....com>
> > Signed-off-by: Feng Tang <feng.tang@...ux.alibaba.com>
[...]
> > +		cpu = (struct acpi_pptt_processor *)entry;
> > +		entry = ACPI_ADD_PTR(struct acpi_subtable_header, entry, len);
> > +		if (cpu->header.type == ACPI_PPTT_TYPE_PROCESSOR &&
> > +		    (cpu->flags & ACPI_PPTT_ACPI_LEAF_NODE))
> > +			nr_pptt_cpus++;
> > +	}
> > +
> > +	if (nr_pptt_cpus != num_possible_cpus())
> 
> This is going to be tricky. I recall some config option that sets all
> `NR_CPUS` as possible. In short it will break if that is enabled.

Thanks for the info.

> > +		pr_warn("The number of CPUs (%d) in PPTT table doesn't match system's CPU count (%d)!\n",
> > +			nr_pptt_cpus, num_possible_cpus());
> > +
> > +	checked = true;
> > +}
> > +
> >  /**
> >   * topology_get_acpi_cpu_tag() - Find a unique topology value for a feature
> >   * @table: Pointer to the head of the PPTT table
> > @@ -565,6 +602,9 @@ static int topology_get_acpi_cpu_tag(struct acpi_table_header *table,
> >  	}
> >  	pr_warn_once("PPTT table found, but unable to locate core %d (%d)\n",
> >  		    cpu, acpi_cpu_id);
> 
> I was expecting the above log will be improved to just say possible mismatch
> with cpu count.
 
Yep. it should be more explicite about the source.

> > +
> > +	/* Check whether PPTT table's CPU count match with system count */
> > +	pptt_verify_cpu_count(table);
> 
> Today it is a request to check the CPU count; tomorrow it will be something
> else in the PPTT. Where do we draw the line on PPTT validation in the kernel?

I had similar concern, so I listed all items in orignal patch for check.

> These issues ultimately need to be fixed in firmware, and the firmware
> should not depend on the kernel to precisely identify what is wrong in
> the PPTT tables.

Ideally yes. But upon the sad experience of raising issue to BIOS vendor or
engineers, the more precise info, the sooner it gets solved and not refused. 

Thanks,
Feng