kernel/linux.git/drivers/base/power/main.c, branch v4.19.112

PM: core: Fix handling of devices deleted during system-wide resume

2020-02-11T12:34:03+00:00

commit 0552e05fdfea191a2cf3a0abd33574b5ef9ca818 upstream. If a device is deleted by one of its system-wide resume callbacks (for example, because it does not appear to be present or accessible any more) along with its children, the resume of the children may continue leading to use-after-free errors and other issues (potentially). Namely, if the device's children are resumed asynchronously, their resume may have been scheduled already before the device's callback runs and so the device may be deleted while dpm_wait_for_superior() is being executed for them. The memory taken up by the parent device object may be freed then while dpm_wait() is waiting for the parent's resume callback to complete, which leads to a use-after-free. Moreover, the resume of the children is really not expected to continue after they have been unregistered, so it must be terminated right away in that case. To address this problem, modify dpm_wait_for_superior() to check if the target device is still there in the system-wide PM list of devices and if so, to increment its parent's reference counter, both under dpm_list_mtx which prevents device_del() running for the child from dropping the parent's reference counter prematurely. If the device is not present in the system-wide PM list of devices any more, the resume of it cannot continue, so check that again after dpm_wait() returns, which means that the parent's callback has been completed, and pass the result of that check to the caller of dpm_wait_for_superior() to allow it to abort the device's resume if it is not there any more. Link: https://lore.kernel.org/linux-pm/1579568452-27253-1-git-send-email-chanho.min@lge.com Reported-by: Chanho Min Cc: All applicable Signed-off-by: Rafael J. Wysocki Acked-by: Greg Kroah-Hartman Signed-off-by: Greg Kroah-Hartman

PM / core: Propagate dev->power.wakeup_path when no callbacks

2019-05-31T13:46:23+00:00

[ Upstream commit dc351d4c5f4fe4d0f274d6d660227be0c3a03317 ] The dev->power.direct_complete flag may become set in device_prepare() in case the device don't have any PM callbacks (dev->power.no_pm_callbacks is set). This leads to a broken behaviour, when there is child having wakeup enabled and relies on its parent to be used in the wakeup path. More precisely, when the direct complete path becomes selected for the child in __device_suspend(), the propagation of the dev->power.wakeup_path becomes skipped as well. Let's address this problem, by checking if the device is a part the wakeup path or has wakeup enabled, then prevent the direct complete path from being used. Reported-by: Loic Pallardy Signed-off-by: Ulf Hansson [ rjw: Comment cleanup ] Signed-off-by: Rafael J. Wysocki Signed-off-by: Sasha Levin

PM / core: Clear the direct_complete flag on errors

2018-10-04T17:39:31+00:00

If __device_suspend() runs asynchronously (in which case the device passed to it is in dpm_suspended_list at that point) and it returns early on an error or pending wakeup, and the power.direct_complete flag has been set for the device already, the subsequent device_resume() will be confused by that and it will call pm_runtime_enable() incorrectly, as runtime PM has not been disabled for the device by __device_suspend(). To avoid that, clear power.direct_complete if __device_suspend() is not going to disable runtime PM for the device before returning. Fixes: aae4518b3124 (PM / sleep: Mechanism to avoid resuming runtime-suspended devices unnecessarily) Reported-by: Al Cooper Tested-by: Al Cooper Reviewed-by: Ulf Hansson Cc: 3.16+ # 3.16+ Signed-off-by: Rafael J. Wysocki

Merge back PM core material for v4.18.

2018-05-25T08:39:39+00:00

PM / core: Fix direct_complete handling for devices with no callbacks

2018-05-22T12:50:11+00:00

Commit 08810a4119aa (PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags) inadvertently prevented the power.direct_complete flag from being set for devices without PM callbacks and with disabled runtime PM which also prevents power.direct_complete from being set for their parents. That led to problems including a resume crash on HP ZBook 14u. Restore the previous behavior by causing power.direct_complete to be set for those devices again, but do that in a more direct way to avoid overlooking that case in the future. Link: https://bugzilla.kernel.org/show_bug.cgi?id=199693 Fixes: 08810a4119aa (PM / core: Add NEVER_SKIP and SMART_PREPARE driver flags) Reported-by: Thomas Martitz Tested-by: Thomas Martitz Cc: 4.15+ # 4.15+ Signed-off-by: Rafael J. Wysocki Reviewed-by: Ulf Hansson Reviewed-by: Johan Hovold

PM / core: Use dev_printk() and symbols in suspend/resume diagnostics

2018-05-10T09:31:45+00:00

When we print diagnostic messages about suspend/resume, we have a device pointer, so use dev_printk() to match other device-related things. Add the function name, similar to initcall_debug output. E.g., - calling 0000:01:00.0+ @ 998, parent: 0000:00:1c.0 + pci 0000:01:00.0: calling @ 998, parent: 0000:00:1c.0 I wondered if this would break scripts/bootgraph.pl, but I don't think it will because bootgraph.pl doesn't add any timing information to $start{} after it sees "Write protecting the" or "Freeing unused kernel memory". Signed-off-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki

PM / core: Simplify initcall_debug_report() timing

2018-05-10T09:31:45+00:00

initcall_debug_report() always called ktime_get(), even if we didn't need the result. Change it so we only call it when we're going to use the result, and change initcall_debug_start() to follow the same style. Signed-off-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki

PM / core: Remove unused initcall_debug_report() arguments

2018-05-10T09:31:45+00:00

Commit e8bca479c3f2 (PM / sleep: trace events for device PM callbacks) removed the only uses of "state" and "info" from initcall_debug_report(). Remove the now-unused arguments completely. Signed-off-by: Bjorn Helgaas Signed-off-by: Rafael J. Wysocki

PM / core: Propagate wakeup_path status flag in __device_suspend_late()

2018-01-10T12:13:57+00:00

Currently the wakeup_path status flag becomes propagated from a child device to its parent device at __device_suspend(). This allows a driver dealing with a parent device to act on the flag from its ->suspend() callback. However, in situations when the wakeup_path status flag needs to be set from a ->suspend_late() callback, its value doesn't get propagated to the parent by the PM core. Let's address this limitation, by also propagating the flag at __device_suspend_late(). Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki

PM / core: Re-structure code for clearing the direct_complete flag

2018-01-10T12:13:56+00:00

To make the code more consistent, let's clear the parent's direct_complete flag along with clearing it for suppliers, instead of as currently, when propagating the wakeup_path flag to parents. While changing this, let's take the opportunity to rename the affected internal functions, to make them self-explanatory. Like this: dpm_clear_suppliers_direct_complete -> dpm_clear_superiors_direct_complete dpm_propagate_to_parent -> dpm_propagate_wakeup_to_parent Signed-off-by: Ulf Hansson Signed-off-by: Rafael J. Wysocki