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: <aWpCpecZr7o0qIw2@bogus>
Date: Fri, 16 Jan 2026 13:52:37 +0000
From: Sudeep Holla <sudeep.holla@....com>
To: Feng Tang <feng.tang@...ux.alibaba.com>
Cc: "Rafael J . Wysocki" <rafael@...nel.org>, Len Brown <lenb@...nel.org>,
	Jeremy Linton <jeremy.linton@....com>,
	Hanjun Guo <guohanjun@...wei.com>,
	Sudeep Holla <sudeep.holla@....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 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>
> ---
> Changelog:
> 
>   v3
>   * Only check the number of CPUs in PPTT table againt system
>     CPU count when error happens, instead of dump all the CPU/cache
> 	entries (Sudeep/Rafael)
> 
>   v2
>   * rebase againt 6.19 and refine the commit log
> 
>  drivers/acpi/pptt.c | 40 ++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 40 insertions(+)
> 
> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
> index de5f8c018333..9958c3961001 100644
> --- a/drivers/acpi/pptt.c
> +++ b/drivers/acpi/pptt.c
> @@ -529,6 +529,43 @@ static void acpi_pptt_warn_missing(void)
>  	pr_warn_once("No PPTT table found, CPU and cache topology may be inaccurate\n");
>  }
>  
> +static void pptt_verify_cpu_count(struct acpi_table_header *table_hdr)
> +{
> +	struct acpi_subtable_header *entry;
> +	unsigned long end;
> +	struct acpi_pptt_processor *cpu;
> +	u8 len;
> +	int nr_pptt_cpus = 0;
> +	static bool checked;
> +
> +	if (checked)
> +		return;
> +
> +	end = (unsigned long)table_hdr + table_hdr->length;
> +	entry = ACPI_ADD_PTR(struct acpi_subtable_header, table_hdr,
> +				sizeof(struct acpi_table_pptt));
> +
> +	while ((unsigned long)entry + sizeof(struct acpi_pptt_processor) <= end) {
> +		len = entry->length;
> +		if (!len) {
> +			pr_warn("Invalid zero length subtable\n");
> +			return;
> +		}
> +
> +		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.

> +		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.

> +
> +	/* 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?
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.

-- 
Regards,
Sudeep