kernel/linux.git/drivers/acpi/processor_idle.c, branch v5.15.209

ACPI: processor: idle: Fix memory leak when register cpuidle device failed

2025-10-19T14:21:29+00:00

[ Upstream commit 11b3de1c03fa9f3b5d17e6d48050bc98b3704420 ] The cpuidle device's memory is leaked when cpuidle device registration fails in acpi_processor_power_init(). Free it as appropriate. Fixes: 3d339dcbb56d ("cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure") Signed-off-by: Huisong Li Link: https://patch.msgid.link/20250728070612.1260859-2-lihuisong@huawei.com [ rjw: Changed the order of the new statements, added empty line after if () ] [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: processor: idle: Check acpi_fetch_acpi_dev() return value

2025-08-28T14:24:33+00:00

commit 2437513a814b3e93bd02879740a8a06e52e2cf7d upstream. The return value of acpi_fetch_acpi_dev() could be NULL, which would cause a NULL pointer dereference to occur in acpi_device_hid(). Signed-off-by: Li Zhong [ rjw: Subject and changelog edits, added empty line after if () ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Teddy Astie Signed-off-by: Yann Sionneau Reported-by: Dillon C Tested-by: Dillon C Signed-off-by: Greg Kroah-Hartman

ACPI: processor: idle: Return an error if both P_LVL{2,3} idle states are invalid

2025-04-10T12:32:02+00:00

[ Upstream commit 9e9b893404d43894d69a18dd2fc8fcf1c36abb7e ] Prior to commit 496121c02127 ("ACPI: processor: idle: Allow probing on platforms with one ACPI C-state"), the acpi_idle driver wouldn't load on systems without a valid C-State at least as deep as C2. The behavior was desirable for guests on hypervisors such as VMWare ESXi, which by default don't have the _CST ACPI method, and set the C2 and C3 latencies to 101 and 1001 microseconds respectively via the FADT, to signify they're unsupported. Since the above change though, these virtualized deployments end up loading acpi_idle, and thus entering the default C1 C-State set by acpi_processor_get_power_info_default(); this is undesirable for a system that's communicating to the OS it doesn't want C-States (missing _CST, and invalid C2/C3 in FADT). Make acpi_processor_get_power_info_fadt() return -ENODEV in that case, so that acpi_processor_get_cstate_info() exits early and doesn't set pr->flags.power = 1. Fixes: 496121c02127 ("ACPI: processor: idle: Allow probing on platforms with one ACPI C-state") Signed-off-by: Giovanni Gherdovich Reviewed-by: Zhang Rui Link: https://patch.msgid.link/20250328143040.9348-1-ggherdovich@suse.cz [ rjw: Changelog edits ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: processor_idle: Fix invalid comparison with insertion sort for latency

2024-07-27T08:46:06+00:00

commit 233323f9b9f828cd7cd5145ad811c1990b692542 upstream. The acpi_cst_latency_cmp() comparison function currently used for sorting C-state latencies does not satisfy transitivity, causing incorrect sorting results. Specifically, if there are two valid acpi_processor_cx elements A and B and one invalid element C, it may occur that A < B, A = C, and B = C. Sorting algorithms assume that if A < B and A = C, then C < B, leading to incorrect ordering. Given the small size of the array (<=8), we replace the library sort function with a simple insertion sort that properly ignores invalid elements and sorts valid ones based on latency. This change ensures correct ordering of the C-state latencies. Fixes: 65ea8f2c6e23 ("ACPI: processor idle: Fix up C-state latency if not ordered") Reported-by: Julian Sikorski Closes: https://lore.kernel.org/lkml/70674dc7-5586-4183-8953-8095567e73df@gmail.com Signed-off-by: Kuan-Wei Chiu Tested-by: Julian Sikorski Cc: All applicable Link: https://patch.msgid.link/20240701205639.117194-1-visitorckw@gmail.com Signed-off-by: Rafael J. Wysocki Signed-off-by: Kuan-Wei Chiu Signed-off-by: Greg Kroah-Hartman

ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()

2024-03-26T22:21:19+00:00

[ Upstream commit e18afcb7b2a12b635ac10081f943fcf84ddacc51 ] After unregistering the CPU idle device, the memory associated with it is not freed, leading to a memory leak: unreferenced object 0xffff896282f6c000 (size 1024): comm "swapper/0", pid 1, jiffies 4294893170 hex dump (first 32 bytes): 00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ backtrace (crc 8836a742): [] kmalloc_trace+0x29d/0x340 [] acpi_processor_power_init+0xf3/0x1c0 [] __acpi_processor_start+0xd3/0xf0 [] acpi_processor_start+0x2c/0x50 [] really_probe+0xe2/0x480 [] __driver_probe_device+0x78/0x160 [] driver_probe_device+0x1f/0x90 [] __driver_attach+0xce/0x1c0 [] bus_for_each_dev+0x70/0xc0 [] bus_add_driver+0x112/0x210 [] driver_register+0x55/0x100 [] acpi_processor_driver_init+0x3b/0xc0 [] do_one_initcall+0x41/0x300 [] kernel_init_freeable+0x320/0x470 [] kernel_init+0x16/0x1b0 [] ret_from_fork+0x2d/0x50 Fix this by freeing the CPU idle device after unregistering it. Fixes: 3d339dcbb56d ("cpuidle / ACPI : move cpuidle_device field out of the acpi_processor_power structure") Signed-off-by: Armin Wolf Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: processor idle: Practically limit "Dummy wait" workaround to old Intel systems

2023-02-06T06:59:01+00:00

commit e400ad8b7e6a1b9102123c6240289a811501f7d9 upstream. Old, circa 2002 chipsets have a bug: they don't go idle when they are supposed to. So, a workaround was added to slow the CPU down and ensure that the CPU waits a bit for the chipset to actually go idle. This workaround is ancient and has been in place in some form since the original kernel ACPI implementation. But, this workaround is very painful on modern systems. The "inl()" can take thousands of cycles (see Link: for some more detailed numbers and some fun kernel archaeology). First and foremost, modern systems should not be using this code. Typical Intel systems have not used it in over a decade because it is horribly inferior to MWAIT-based idle. Despite this, people do seem to be tripping over this workaround on AMD system today. Limit the "dummy wait" workaround to Intel systems. Keep Modern AMD systems from tripping over the workaround. Remotely modern Intel systems use intel_idle instead of this code and will, in practice, remain unaffected by the dummy wait. Reported-by: K Prateek Nayak Suggested-by: Rafael J. Wysocki Signed-off-by: Dave Hansen Reviewed-by: Mario Limonciello Tested-by: K Prateek Nayak Link: https://lore.kernel.org/all/20220921063638.2489-1-kprateek.nayak@amd.com/ Link: https://lkml.kernel.org/r/20220922184745.3252932-1-dave.hansen@intel.com Signed-off-by: Guilherme G. Piccoli Signed-off-by: Greg Kroah-Hartman

ACPI: processor/idle: Annotate more functions to live in cpuidle section

2022-08-17T12:23:06+00:00

[ Upstream commit 409dfdcaffb266acfc1f33529a26b1443c9332d4 ] Commit 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus") introduced a new text section called cpuidle; with that, we have a mechanism to add idling functions in such section and skip them from nmi_backtrace output, since they're useless and potentially flooding for such report. Happens that inlining might cause some real idle functions to end-up outside of such section; this is currently the case of ACPI processor_idle driver; the functions acpi_idle_enter_* do inline acpi_idle_do_entry(), hence they stay out of the cpuidle section. Fix that by marking such functions to also live in the cpuidle section. Fixes: 6727ad9e206c ("nmi_backtrace: generate one-line reports for idle cpus") Signed-off-by: Guilherme G. Piccoli Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

ACPI: processor: idle: Avoid falling back to C3 type C-states

2022-05-09T07:14:41+00:00

commit fc45e55ebc58dbf622cb89ddbf797589c7a5510b upstream. The "safe state" index is used by acpi_idle_enter_bm() to avoid entering a C-state that may require bus mastering to be disabled on entry in the cases when this is not going to happen. For this reason, it should not be set to point to C3 type of C-states, because they may require bus mastering to be disabled on entry in principle. This was broken by commit d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state") which inadvertently allowed the "safe state" index to point to C3 type of C-states. This results in a machine that won't boot past the point when it first enters C3. Restore the correct behaviour (either demote to C1/C2, or use C3 but also set ARB_DIS=1). I hit this on a Fujitsu Siemens Lifebook S6010 (P3) machine. Fixes: d6b88ce2eb9d ("ACPI: processor idle: Allow playing dead in C3 state") Cc: 5.16+ # 5.16+ Signed-off-by: Ville Syrjälä Tested-by: Woody Suwalski [ rjw: Subject and changelog adjustments ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

Revert "ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40"

2022-05-09T07:14:41+00:00

commit 20e582e16af24b074e583f9551fad557882a3c9d upstream. This reverts commit bfe55a1f7fd6bfede16078bf04c6250fbca11588. This was presumably misdiagnosed as an inability to use C3 at all when I suspect the real problem is just misconfiguration of C3 vs. ARB_DIS. Signed-off-by: Ville Syrjälä Cc: 5.16+ # 5.16+ Tested-by: Woody Suwalski Signed-off-by: Rafael J. Wysocki Signed-off-by: Greg Kroah-Hartman

ACPI: processor: idle: fix lockup regression on 32-bit ThinkPad T40

2022-04-20T07:34:04+00:00

commit bfe55a1f7fd6bfede16078bf04c6250fbca11588 upstream. Add and ACPI idle power level limit for 32-bit ThinkPad T40. There is a regression on T40 introduced by commit d6b88ce2, starting with kernel 5.16: commit d6b88ce2eb9d2698eb24451eb92c0a1649b17bb1 Author: Richard Gong Date: Wed Sep 22 08:31:16 2021 -0500 ACPI: processor idle: Allow playing dead in C3 state The above patch is trying to enter C3 state during init, what is causing a T40 system freeze. I have not found a similar issue on any other of my 32-bit machines. The fix is to add another exception to the processor_power_dmi_table[] list. As a result the dmesg shows as expected: [2.155398] ACPI: IBM ThinkPad T40 detected - limiting to C2 max_cstate. Override with "processor.max_cstate=9" [2.155404] ACPI: processor limited to max C-state 2 The fix is trivial and affects only vintage T40 systems. Fixes: d6b88ce2eb9d ("CPI: processor idle: Allow playing dead in C3 state") Signed-off-by: Woody Suwalski Reviewed-by: Hans de Goede Cc: 5.16+ # 5.16+ [ rjw: New subject ] Signed-off-by: Rafael J. Wysocki Cc: "Limonciello, Mario" Signed-off-by: Greg Kroah-Hartman