From: Sudeep Holla <sudeep.holla@arm.com>
To: Jeremy Linton <jeremy.linton@arm.com>
Cc: <rafael@kernel.org>, <lenb@kernel.org>, <jmeurin@google.com>,
<linux-acpi@vger.kernel.org>, <linux-kernel@vger.kernel.org>,
Maximilian Heyne <mheyne@amazon.de>,
Sudeep Holla <sudeep.holla@arm.com>,
Yicong Yang <yangyicong@hisilicon.com>, <stable@vger.kernel.org>
Subject: Re: [PATCH] ACPI: PPTT: Fix processor subtable walk
Date: Thu, 8 May 2025 10:12:58 +0100 [thread overview]
Message-ID: <20250508-abiding-enigmatic-mustang-ab3bd2@sudeepholla> (raw)
In-Reply-To: <20250508023025.1301030-1-jeremy.linton@arm.com>
On Wed, May 07, 2025 at 09:30:25PM -0500, Jeremy Linton wrote:
> The original PPTT code had a bug where the processor subtable length
> was not correctly validated when encountering a truncated
> acpi_pptt_processor node.
>
> Commit 7ab4f0e37a0f4 ("ACPI PPTT: Fix coding mistakes in a couple of
> sizeof() calls") attempted to fix this by validating the size is as
> large as the acpi_pptt_processor node structure. This introduced a
> regression where the last processor node in the PPTT table is ignored
> if it doesn't contain any private resources. That results errors like:
>
> ACPI PPTT: PPTT table found, but unable to locate core XX (XX)
> ACPI: SPE must be homogeneous
>
> Furthermore, it fail in a common case where the node length isn't
> equal to the acpi_pptt_processor structure size, leaving the original
> bug in a modified form.
>
> Correct the regression by adjusting the loop termination conditions as
> suggested by the bug reporters. An additional check performed after
> the subtable node type is detected, validates the acpi_pptt_processor
> node is fully contained in the PPTT table. Repeating the check in
> acpi_pptt_leaf_node() is largely redundant as the node is already
> known to be fully contained in the table.
>
> The case where a final truncated node's parent property is accepted,
> but the node itself is rejected should not be considered a bug.
>
Thanks for picking this up and describing the issue properly in the commit
message.
Reviewed-by: Sudeep Holla <sudeep.holla@arm.com>
--
Regards,
Sudeep
next prev parent reply other threads:[~2025-05-08 9:13 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-08 2:30 [PATCH] ACPI: PPTT: Fix processor subtable walk Jeremy Linton
2025-05-08 4:00 ` Yicong Yang
2025-05-08 9:12 ` Sudeep Holla [this message]
2025-05-08 18:26 ` Rafael J. Wysocki
2025-05-08 14:50 ` Heyne, Maximilian
2025-05-14 13:07 ` Aishwarya
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250508-abiding-enigmatic-mustang-ab3bd2@sudeepholla \
--to=sudeep.holla@arm.com \
--cc=jeremy.linton@arm.com \
--cc=jmeurin@google.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mheyne@amazon.de \
--cc=rafael@kernel.org \
--cc=stable@vger.kernel.org \
--cc=yangyicong@hisilicon.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.