Commit-ID: 8237bded3959c6d038798b905485d3ba94b8ea10
Gitweb: http://git.kernel.org/tip/8237bded3959c6d038798b905485d3ba94b8ea10
Author: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
AuthorDate: Fri, 7 Oct 2016 14:02:12 +0200
Committer: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
CommitDate: Fri, 7 Oct 2016 15:22:15 +0200
x86/acpi: Prevent LAPIC id 0xff from being accounted
Yinghai reported that the recent changes to make the cpuid - nodeid
relationship permanent causes a cpuid ordering regression on a system which
has 2apic enabled..
The reason is that the ACPI local APIC parser has no sanity check for
apicid 0xff, which is an invalid id. So a CPU id for this invalid local
APIC id is allocated and therefor breaks the cpuid ordering.
Add a sanity check to acpi_parse_lapic() which ignores the invalid id.
Fixes: 8f54969dc8d6 ("x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping")
Reported-by: Yinghai Lu <yinghai@xxxxxxxxxx>
Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx>
Cc: Gu Zheng <guz.fnst@xxxxxxxxxxxxxx>,
Cc: Tang Chen <tangchen@xxxxxxxxxxxxxx>
Cc: douly.fnst@xxxxxxxxxxxxxx,
Cc: zhugh.fnst@xxxxxxxxxxxxxx
Cc: Tony Luck <tony.luck@xxxxxxxxx>
Cc: Rafael J. Wysocki <rjw@xxxxxxxxxxxxx>
Cc: Len Brown <lenb@xxxxxxxxxx>
Cc: Lv Zheng <lv.zheng@xxxxxxxxx>,
Cc: robert.moore@xxxxxxxxx
Cc: linux-acpi@xxxxxxxxxxxxxxx
Link: https://lkml.kernel.org/r/CAE9FiQVQx6FRXT-RdR7Crz4dg5LeUWHcUSy1KacjR+JgU_vGJg@xxxxxxxxxxxxxx
---
arch/x86/kernel/acpi/boot.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/x86/kernel/acpi/boot.c b/arch/x86/kernel/acpi/boot.c
index 32a7d70..6d35baf 100644
--- a/arch/x86/kernel/acpi/boot.c
+++ b/arch/x86/kernel/acpi/boot.c
@@ -233,6 +233,9 @@ acpi_parse_lapic(struct acpi_subtable_header * header, const unsigned long end)
acpi_table_print_madt_entry(header);
+ if (processor->id >= 0xff)
+ return -EINVAL;
+
/*
* We need to register disabled CPU as well to permit
* counting disabled CPUs. This allows us to size
--
To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
|