On Tue, May 06, 2025 at 08:08:47PM +0000, Heyne, Maximilian wrote:
On Tue, May 06, 2025 at 02:43:39PM +0100, Sudeep Holla wrote:
On Tue, May 06, 2025 at 01:13:02PM +0000, Heyne, Maximilian wrote:
Commit 7ab4f0e37a0f ("ACPI PPTT: Fix coding mistakes in a couple of sizeof() calls") corrects the processer entry size but unmasked a longer standing bug where the last entry in the structure can get skipped due to an off-by-one mistake if the last entry ends exactly at the end of the ACPI subtable.
Unless the firmware has populated an incorrect value for the header length, I don't see how this is possible. The table_end should point to the address immediately following the last byte of the table. None of the headers are only one byte long, so what am I missing that could explain this apparent off-by-one issue?.
-- Regards, Sudeep
Maybe calling it off-by-one is not very exact. You're right table_end points to the address following the last byte *but* (unsigned long)entry + proc_sz also points to this very byte if it's the last entry. And in this case the while condition is not taken which means we're ignoring the last processor node.
For example, in our specific case the table has a length of 0xCBE and the last processor node entry is at 0xCAA with a length of 0x14 fitting exactly into the table but 0xCAA + 0x14 == 0xCBE which turns the condition false.
Just to understand, this node is absolutely processor node with no private resources ? I find it hard to trust this as most of the CPUs do have L1 I&D caches. If they were present the table can't abruptly end like this.