kernel.git/drivers/acpi/acpi_pad.c, branch linux-4.4.y

ACPI: acpi_pad: Fix memory leak in power saving threads

2018-05-30T05:49:09Z

[ Upstream commit 8b29d29abc484d638213dd79a18a95ae7e5bb402 ] Fix once per second (round_robin_time) memory leak of about 1 KB in each acpi_pad kernel idling thread that is activated. Found by testing with kmemleak. Signed-off-by: Lenny Szubowicz Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin Signed-off-by: Greg Kroah-Hartman

ACPI / PAD: power_saving_thread() is not freezable

2015-10-26T03:42:54Z

power_saving_thread() calls try_to_freeze(), but the thread doesn't mark itself freezable through set_freezable(), so the try_to_freeze() call is useless. Signed-off-by: Jiri Kosina Signed-off-by: Rafael J. Wysocki

ACPI: Remove FSF mailing addresses

2015-07-08T00:27:32Z

There is no need to carry potentially outdated Free Software Foundation mailing address in file headers since the COPYING file includes it. Signed-off-by: Jarkko Nikula Signed-off-by: Rafael J. Wysocki

sched/topology: Rename topology_thread_cpumask() to topology_sibling_cpumask()

2015-05-27T13:22:15Z

Rename topology_thread_cpumask() to topology_sibling_cpumask() for more consistency with scheduler code. Signed-off-by: Bartosz Golaszewski Reviewed-by: Thomas Gleixner Acked-by: Russell King Acked-by: Catalin Marinas Cc: Benoit Cousson Cc: Fenghua Yu Cc: Guenter Roeck Cc: Jean Delvare Cc: Jonathan Corbet Cc: Linus Torvalds Cc: Oleg Drokin Cc: Peter Zijlstra Cc: Rafael J. Wysocki Cc: Russell King Cc: Viresh Kumar Link: http://lkml.kernel.org/r/1432645896-12588-2-git-send-email-bgolaszewski@baylibre.com Signed-off-by: Ingo Molnar

ACPI/PAD: Use explicit broadcast oneshot control function

2015-04-03T06:44:34Z

Replace the clockevents_notify() call with an explicit function call. Signed-off-by: Thomas Gleixner Signed-off-by: Rafael J. Wysocki Cc: Len Brown Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1552509.UntNmyqF5v@vostro.rjw.lan Signed-off-by: Ingo Molnar

ACPI/PAD: Use explicit broadcast control function

2015-04-03T06:44:32Z

Replace the clockevents_notify() call with an explicit function call. Signed-off-by: Thomas Gleixner Signed-off-by: Rafael J. Wysocki Cc: Len Brown Cc: Peter Zijlstra Link: http://lkml.kernel.org/r/1521832.mm0ZfkTzTA@vostro.rjw.lan Signed-off-by: Ingo Molnar

ACPI/PAD: Remove the local APIC nonsense

2015-04-03T06:44:31Z

While looking through the (ab)use of the clockevents_notify() function I stumbled over the following gem in the acpi_pad code: if (lapic_detected_unstable && !lapic_marked_unstable) { /* LAPIC could halt in idle, so notify users */ for_each_online_cpu(i) clockevents_notify(CLOCK_EVT_NOTIFY_BROADCAST_ON, &i); lapic_marked_unstable = 1; } This code calls on the cpu which detects the lapic unstable condition first clockevents_notify() to tell the core code that the broadcast should be enabled on all online cpus. Brilliant stuff that as it notifies the core code a num_online_cpus() times that the broadcast should be enabled on the current cpu. This probably has never been noticed because that code got never tested with NOHZ=n and HIGHRES_TIMER=n or it just worked by chance because one of the other mechanisms told the core in the right way that the local apic timer is wreckaged. Sigh, this is: - The 4th incarnation of idle drivers which has their own mechanism to detect and deal with X86_FEATURE_ARAT. - The 2nd incarnation of fake idle mechanisms with a different set of brainmelting bugs. - Has been merged against an explicit NAK of the scheduler maintainer with the promise to improve it over time. - Another example of featuritis driven trainwreck engineering. - Another pointless waste of my time. Fix this nonsense by removing that lapic detection and notification logic and simply call into the clockevents code unconditonally. The ARAT feature is marked in the lapic clockevent already so the core code will just ignore the requests and return. Signed-off-by: Thomas Gleixner Signed-off-by: Rafael J. Wysocki Cc: Peter Zijlstra Cc: Borislav Petkov Cc: H. Peter Anvin Cc: Linus Torvalds Cc: Thomas Gleixner Link: http://lkml.kernel.org/r/1887788.RObRuI4tSv@vostro.rjw.lan Signed-off-by: Ingo Molnar

cpumask: factor out show_cpumap into separate helper function

2014-11-07T19:45:00Z

Many sysfs *_show function use cpu{list,mask}_scnprintf to copy cpumap to the buffer aligned to PAGE_SIZE, append '\n' and '\0' to return null terminated buffer with newline. This patch creates a new helper function cpumap_print_to_pagebuf in cpumask.h using newly added bitmap_print_to_pagebuf and consolidates most of those sysfs functions using the new helper function. Signed-off-by: Sudeep Holla Suggested-by: Stephen Boyd Tested-by: Stephen Boyd Acked-by: "Rafael J. Wysocki" Acked-by: Bjorn Helgaas Acked-by: Peter Zijlstra (Intel) Cc: Greg Kroah-Hartman Cc: x86@kernel.org Cc: linux-acpi@vger.kernel.org Cc: linux-pci@vger.kernel.org Signed-off-by: Greg Kroah-Hartman

ACPI / PAD: Use time_before() for time comparison

2014-05-26T23:38:23Z

To be future-proof and for better readability the time comparisons are modified to use time_before() instead of plain, error-prone math. Signed-off-by: Manuel Schölling Signed-off-by: Rafael J. Wysocki

ACPI / PAD: call schedule() when need_resched() is true

2014-04-28T10:26:00Z

The purpose of the acpi_pad driver is to implement the "processor power aggregator" device as described in the ACPI 4.0 spec section 8.5. It takes requests from the BIOS (via ACPI) to put a specified number of CPUs into idle, in order to save power, until further notice. It does this by creating high-priority threads that try to keep the CPUs in a high C-state (using the monitor/mwait CPU instructions). The mwait() call is in a loop that checks periodically if the thread should end and a few other things. It was discovered through testing that the power_saving threads were causing the system to consume more power than the system was consuming before the threads were created. A counter in the main loop of power_saving_thread() revealed that it was spinning. The mwait() instruction was not keeping the CPU in a high C state very much if at all. Here is a simplification of the loop in function power_saving_thread() in drivers/acpi/acpi_pad.c while (!kthread_should_stop()) { : try_to_freeze() : while (!need_resched()) { : if (!need_resched()) __mwait(power_saving_mwait_eax, 1); : if (jiffies > expire_time) { do_sleep = 1; break; } } } If need_resched() returns true, then mwait() is not called. It was returning true because of things like timer interrupts, as in the following sequence. hrtimer_interrupt->__run_hrtimer->tick_sched_timer-> update_process_times-> rcu_check_callbacks->rcu_pending->__rcu_pending->set_need_resched Kernels 3.5.0-rc2+ do not exhibit this problem, because a patch to try_to_freeze() in include/linux/freezer.h introduces a call to might_sleep(), which ultimately calls schedule() to clear the reschedule flag and allows the the loop to execute the call to mwait(). However, the changes to try_to_freeze are unrelated to acpi_pad, and it does not seem like a good idea to rely on an unrelated patch in a function that could later be changed and reintroduce this bug. Therefore, it seems better to make an explicit call to schedule() in the outer loop when the need_resched flag is set. Reported-and-tested-by: Stuart Hayes Signed-off-by: Tony Camuso Signed-off-by: Rafael J. Wysocki