Patch "x86/acpi: Restore the order of CPU IDs" has been added to the 4.9-stable tree

This is a note to let you know that I've just added the patch titled

x86/acpi: Restore the order of CPU IDs

to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
x86-acpi-restore-the-order-of-cpu-ids.patch
and it can be found in the queue-4.9 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

From: Dou Liyang <[email protected]>
Date: Fri, 3 Mar 2017 16:02:25 +0800
Subject: x86/acpi: Restore the order of CPU IDs

From: Dou Liyang <[email protected]>

[ Upstream commit 2b85b3d22920db7473e5fed5719e7955c0ec323e ]

The following commits:

f7c28833c2 ("x86/acpi: Enable acpi to register all possible cpus at
boot time") and 8f54969dc8 ("x86/acpi: Introduce persistent storage for cpuid <-> apicid mapping")

... registered all the possible CPUs at boot time via ACPI tables to make the mapping of cpuid <-> apicid fixed. Both enabled and disabled CPUs could have a logical CPU ID after boot time.

But, ACPI tables are unreliable. the number amd order of Local APIC entries which depends on the firmware is often inconsistent with the physical devices. Even if they are consistent, The disabled CPUs which take up some logical CPU IDs will also make the order discontinuous.

Revert the part of disabled CPUs registration, keep the allocation logic of logical CPU IDs and also keep some code location changes.

---
 arch/x86/kernel/acpi/boot.c |    7 ++++++-
 arch/x86/kernel/apic/apic.c |   26 +++++++-------------------
 2 files changed, 13 insertions(+), 20 deletions(-)

@@ -176,10 +176,15 @@ static int acpi_register_lapic(int id, u
 		return -EINVAL;
 	}
 
+	if (!enabled) {
+		++disabled_cpus;
+		return -EINVAL;
+	}
+
 	if (boot_cpu_physical_apicid != -1U)
 		ver = boot_cpu_apic_version;
 
-	cpu = __generic_processor_info(id, ver, enabled);
+	cpu = generic_processor_info(id, ver);
 	if (cpu >= 0)
 		early_per_cpu(x86_cpu_to_acpiid, cpu) = acpiid;
 

@@ -2070,7 +2070,7 @@ static int allocate_logical_cpuid(int ap
 	return nr_logical_cpuids++;
 }
 
-int __generic_processor_info(int apicid, int version, bool enabled)
+int generic_processor_info(int apicid, int version)
 {
 	int cpu, max = nr_cpu_ids;
 	bool boot_cpu_detected = physid_isset(boot_cpu_physical_apicid,

@@ -2128,11 +2128,9 @@ int __generic_processor_info(int apicid,
 	if (num_processors >= nr_cpu_ids) {
 		int thiscpu = max + disabled_cpus;
 
-		if (enabled) {
-			pr_warning("APIC: NR_CPUS/possible_cpus limit of %i "
-				   "reached. Processor %d/0x%x ignored.\n",
-				   max, thiscpu, apicid);
-		}
+		pr_warning("APIC: NR_CPUS/possible_cpus limit of %i "
+			   "reached. Processor %d/0x%x ignored.\n",
+			   max, thiscpu, apicid);
 
 		disabled_cpus++;
 		return -EINVAL;

@@ -2184,23 +2182,13 @@ int __generic_processor_info(int apicid,
 		apic->x86_32_early_logical_apicid(cpu);
 #endif
 	set_cpu_possible(cpu, true);
-
-	if (enabled) {
-		num_processors++;
-		physid_set(apicid, phys_cpu_present_map);
-		set_cpu_present(cpu, true);
-	} else {
-		disabled_cpus++;
-	}
+	physid_set(apicid, phys_cpu_present_map);
+	set_cpu_present(cpu, true);
+	num_processors++;
 
 	return cpu;
 }
 
-int generic_processor_info(int apicid, int version)
-{
-	return __generic_processor_info(apicid, version, true);
-}
-
 int hard_smp_processor_id(void)
 {
 	return read_apic_id();

Patches currently in stable-queue which might be from [email protected] are

queue-4.9/x86-acpi-restore-the-order-of-cpu-ids.patch

Hi Greg,

Dao found a bug in Linux 4.9 LTS which shows below.

The reason of the bug is that we just backport the patch titled

x86/acpi: Restore the order of CPU IDs

but, ignored the other patches in the series[1].

IMO, the commit c962cff17dfa

("Revert "x86/acpi: Set persistent cpuid <-> nodeid mapping when
booting"")

in the series can fixed this bug. I suggest to backport it.

BTW, I read the rules in Documentation/process/stable-kernel-rules.rst, and found that:

...
- It cannot be bigger than 100 lines, with context.
...

I guess it seems that it's the reason why it did not be pulled in stable tree. Is it right? Can you tell more details about it. :-)

[1] https://lkml.org/lkml/2017/3/3/71

Thanks,
dou.

...

[    3.210401] BUG: unable to handle kernel NULL pointer dereference at 
         (null)
[    3.219161] IP: [<ffffffffa5e77158>] __queue_work+0x78/0x420
[    3.225491] PGD 0 [    3.227537]
[    3.229205] Oops: 0000 [#1] SMP
[    3.232707] Modules linked in:
[    3.236124] CPU: 25 PID: 1 Comm: swapper/0 Not tainted 4.9.59-cloudflare-2017.10.3 #1
[    3.244857] Hardware name: IBM x3630M4 -[7158OCN]-/00KF922, BIOS -[BEE142AUS-1.71]- 07/30/2014
[    3.254461] task: ffff8dc2b2281e00 task.stack: ffffaa348c474000
[    3.261068] RIP: 0010:[<ffffffffa5e77158>]  [<ffffffffa5e77158>] __queue_work+0x78/0x420
[    3.270112] RSP: 0000:ffffaa348c477cb0  EFLAGS: 00010046
[    3.276039] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
[    3.284002] RDX: ffff8dc2b0272000 RSI: 000000007fffffff RDI: ffff8dc2b0272000
[    3.291965] RBP: ffffaa348c477ce8 R08: 000000000001b3a0 R09: ffff8dc2be807840
[    3.299929] R10: 0000000000ffff0a R11: 0000000000000003 R12: ffff8dc2b0272000
[    3.307894] R13: 0000000000000200 R14: ffff8dc2be8a2000 R15: 0000000000013198
[    3.315857] FS:  0000000000000000(0000) GS:ffff8dc2bf440000(0000) knlGS:0000000000000000
[    3.324890] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    3.331301] CR2: 0000000000000000 CR3: 00000001a2c07000 CR4: 00000000001406e0
[    3.339264] Stack:
[    3.341505]  ffff8dc2afcea000 0000001900000800 0000000000000246 0000000000000000
[    3.349801]  0000000000000000 ffffffffa686bdbd ffff8dc2b13e39c0 ffffaa348c477d00
[    3.358094]  ffffffffa5e77519 ffff8dc2b0272000 ffffaa348c477d40 ffffffffa5e73eae
[    3.366390] Call Trace:
[    3.369121]  [<ffffffffa5e77519>] queue_work_on+0x19/0x30
[    3.375146]  [<ffffffffa5e73eae>] call_usermodehelper_exec+0x7e/0x130
[    3.382337]  [<ffffffffa6242157>] kobject_uevent_env+0x4b7/0x510
[    3.389033]  [<ffffffffa62421bb>] kobject_uevent+0xb/0x10
[    3.395058]  [<ffffffffa62416e9>] kset_register+0x59/0x70
[    3.401086]  [<ffffffffa63268b0>] bus_register+0xd0/0x260
[    3.407114]  [<ffffffffa6bdd7bf>] ? acpi_int340x_thermal_init+0x12/0x12
[    3.414496]  [<ffffffffa6bdd7cf>] pnp_init+0x10/0x12
[    3.420039]  [<ffffffffa5e00440>] do_one_initcall+0x50/0x180
[    3.426357]  [<ffffffffa6b97077>] kernel_init_freeable+0x1a2/0x22a
[    3.433258]  [<ffffffffa655df40>] ? rest_init+0x80/0x80
[    3.439089]  [<ffffffffa655df4e>] kernel_init+0xe/0x100
[    3.444921]  [<ffffffffa6564da2>] ret_from_fork+0x22/0x30
[    3.450945] Code: 00 00 41 f6 86 00 01 00 00 02 0f 85 ee 00 0

...

Thanks! I'll include the fix with my next pull request to Greg (unless Greg includes it first).

The actual reason they were not originally pulled in stable is that they're not tagged as such. See Documentation/process/stable-kernel-rules.rst which describes how to do that.

Thanks,
Sasha