linux-kernel - Re: [PATCH v2] ACPI: PPTT: Dump PPTT table when error detected

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAJZ5v0h-hjrE85_=6YOJ6oRRZ4=SmKWrs7hCKnrP6_KZTuDePw@mail.gmail.com>
Date: Wed, 14 Jan 2026 12:36:58 +0100
From: "Rafael J. Wysocki" <rafael@...nel.org>
To: Feng Tang <feng.tang@...ux.alibaba.com>
Cc: Sudeep Holla <sudeep.holla@....com>, "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 v2] ACPI: PPTT: Dump PPTT table when error detected

On Wed, Jan 14, 2026 at 8:07 AM Feng Tang <feng.tang@...ux.alibaba.com> wrote:
>
> Hi Sudeep,
>
> On Tue, Jan 13, 2026 at 02:40:56PM +0000, Sudeep Holla wrote:
> [...]
> > > > >
> > > > > With this, the root cause of the original issue was pretty obvious,
> > > > > that there were some caches items missing which caused the issue when
> > > > > building up scheduler domain.
> > > > >
> > > >
> > > > While this may sound like a good idea, it deviates from how errors in other
> > > > table-parsing code are handled. Instead of dumping the entire table, it would
> > > > be preferable to report the specific issue encountered during parsing.
> > > >
> > > > I do not have a strong objection if Rafael is comfortable with this approach;
> > > > however, it does differ from the established pattern used by similar code.
> > > > Dumping the entire table in a custom manner is not the standard way of
> > > > handling parsing errors. Just my opinion.
> > >
> > > Yes, it's a fair point about the error handling. Actually for the issue
> > > we met, the PPTT table complies with ACPI spec and PPTT table spec nicely,
> > > that it has no checksum or format issue, the only problem is some items
> > > are missing.
> > >
> >
> > Agreed, but how is this any different from other tables that contain optional
> > entries the ASL compiler cannot detect?
> >
> > > So I would say the dump itself doesn't break any existing ACPI table error
> > > handling, or change anything. As Hanjun suggested, it could be put under a
> > > CONFIG_ACPI_PPTT_ERR_DUMP option as a PPTT specific debug method, and not
> > > related to general ACPI table error handling.
> > >
> >
> > Sure, that could be an option as long as CONFIG_ACPI_PPTT_ERR_DUMP is default
> > off and are enabled only when debugging and not always like in distro images.
> > Does that work for you ?
>
> Yes. It sounds great to me.
>
> > > We have had this in our tree for a while, and the good part is it gives a
> > > direct overview of all the processors and caches in system, you get to
> > > know the rough number of them from the index, and items are listed side
> > > by side so that some minor error could be very obvious in this comparing
> > > mode.
> > >
> >
> > Agreed, but all this info are available to userspace in some form already.
> > What does this dump give other than debugging a broken PPTT ?
>
> It is mainly for debugging issues. Though we locally has option to dump it
> on boot unconditionally to help kernel/BIOS devleoper to have a quick
> overview of the PPTT table, as the table gets updated from time to time,
> or sometime the kernel could fail before booting to user space.

The kernel message buffer is not a great place for dumping ACPI tables though.

If an invalid PPTT prevents the system from booting, print out enough
information to identify the cause of the failure.

For everything else, use the tools in user space.