linux-stable.git/drivers/base/power/runtime.c, branch linux-4.9.y

PM / runtime: Avoid false-positive warnings from might_sleep_if()

2017-06-17T04:41:51+00:00

[ Upstream commit a9306a63631493afc75893a4ac405d4e1cbae6aa ]

The might_sleep_if() assertions in __pm_runtime_idle(),
__pm_runtime_suspend() and __pm_runtime_resume() may generate
false-positive warnings in some situations.  For example, that
happens if a nested pm_runtime_get_sync()/pm_runtime_put() pair
is executed with disabled interrupts within an outer
pm_runtime_get_sync()/pm_runtime_put() section for the same device.
[Generally, pm_runtime_get_sync() may sleep, so it should not be
called with disabled interrupts, but in this particular case the
previous pm_runtime_get_sync() guarantees that the device will not
be suspended, so the inner pm_runtime_get_sync() will return
immediately after incrementing the device's usage counter.]

That started to happen in the i915 driver in 4.10-rc, leading to
the following splat:

 BUG: sleeping function called from invalid context at drivers/base/power/runtime.c:1032
 in_atomic(): 1, irqs_disabled(): 0, pid: 1500, name: Xorg
 1 lock held by Xorg/1500:
  #0:  (&dev->struct_mutex){+.+.+.}, at:
  [] i915_mutex_lock_interruptible+0x43/0x140 [i915]
 CPU: 0 PID: 1500 Comm: Xorg Not tainted
 Call Trace:
  dump_stack+0x85/0xc2
  ___might_sleep+0x196/0x260
  __might_sleep+0x53/0xb0
  __pm_runtime_resume+0x7a/0x90
  intel_runtime_pm_get+0x25/0x90 [i915]
  aliasing_gtt_bind_vma+0xaa/0xf0 [i915]
  i915_vma_bind+0xaf/0x1e0 [i915]
  i915_gem_execbuffer_relocate_entry+0x513/0x6f0 [i915]
  i915_gem_execbuffer_relocate_vma.isra.34+0x188/0x250 [i915]
  ? trace_hardirqs_on+0xd/0x10
  ? i915_gem_execbuffer_reserve_vma.isra.31+0x152/0x1f0 [i915]
  ? i915_gem_execbuffer_reserve.isra.32+0x372/0x3a0 [i915]
  i915_gem_do_execbuffer.isra.38+0xa70/0x1a40 [i915]
  ? __might_fault+0x4e/0xb0
  i915_gem_execbuffer2+0xc5/0x260 [i915]
  ? __might_fault+0x4e/0xb0
  drm_ioctl+0x206/0x450 [drm]
  ? i915_gem_execbuffer+0x340/0x340 [i915]
  ? __fget+0x5/0x200
  do_vfs_ioctl+0x91/0x6f0
  ? __fget+0x111/0x200
  ? __fget+0x5/0x200
  SyS_ioctl+0x79/0x90
  entry_SYSCALL_64_fastpath+0x23/0xc6

even though the code triggering it is correct.

Unfortunately, the might_sleep_if() assertions in question are
too coarse-grained to cover such cases correctly, so make them
a bit less sensitive in order to avoid the false-positives.

Reported-and-tested-by: Sedat Dilek 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Sasha Levin 
Signed-off-by: Greg Kroah-Hartman

PM / wakeirq: Fix dedicated wakeirq for drivers not using autosuspend

2017-01-12T10:39:31+00:00

commit bed570307ed78f21b77cb04a1df781dee4a8f05a upstream.

I noticed some wakeirq flakeyness with consumer drivers not using
autosuspend. For drivers not using autosuspend, the wakeirq may never
get unmasked in rpm_suspend() because of irq desc->depth.

We are configuring dedicated wakeirqs to start with IRQ_NOAUTOEN as we
naturally don't want them running until rpm_suspend() is called.

However, when a consumer driver initially calls pm_runtime_get(), we
now wrongly start with disable_irq_nosync() call on the dedicated
wakeirq that is disabled to start with.

This causes desc->depth to toggle between 1 and 2 instead of the usual
0 and 1. This can prevent enable_irq() from unmasking the wakeirq as
that only happens at desc->depth 1.

This does not necessarily show up with drivers using autosuspend as
there is time for disable_irq_nosync() before rpm_suspend() gets called
after the autosuspend timeout.

Let's fix the issue by adding wirq->status that lazily gets set on
the first rpm_suspend(). We also need PM runtime core private functions
for dev_pm_enable_wake_irq_check() and dev_pm_disable_wake_irq_check()
so we can enable the dedicated wakeirq on the first rpm_suspend().

While at it, let's also fix the comments for dev_pm_enable_wake_irq()
and dev_pm_disable_wake_irq(). Those can still be used by the consumer
drivers as needed because the IRQ core manages the interrupt usecount
for us.

Fixes: 4990d4fe327b (PM / Wakeirq: Add automated device wake IRQ handling)
Signed-off-by: Tony Lindgren 
Signed-off-by: Rafael J. Wysocki 
Signed-off-by: Greg Kroah-Hartman

PM / runtime: Use _rcuidle for runtime suspend tracepoints

2016-09-16T00:59:58+00:00

Further testing with false negatives suppressed by commit 293e2421fe25
("rcu: Remove superfluous versions of rcu_read_lock_sched_held()")
identified a few more unprotected uses of RCU from the idle loop.
Because RCU actively ignores idle-loop code (for energy-efficiency
reasons, among other things), using RCU from the idle loop can result
in too-short grace periods, in turn resulting in arbitrary misbehavior.

The affected function is rpm_suspend().

The resulting lockdep-RCU splat is as follows:

------------------------------------------------------------------------

Warning from omap3

===============================
[ INFO: suspicious RCU usage. ]
4.6.0-rc5-next-20160426+ #1112 Not tainted
-------------------------------
include/trace/events/rpm.h:63 suspicious rcu_dereference_check() usage!

other info that might help us debug this:

RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 0
RCU used illegally from extended quiescent state!
1 lock held by swapper/0/0:
 #0:  (&(&dev->power.lock)->rlock){-.-...}, at: [] __pm_runtime_suspend+0x54/0x84

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1112
Hardware name: Generic OMAP36xx (Flattened Device Tree)
[] (unwind_backtrace) from [] (show_stack+0x10/0x14)
[] (show_stack) from [] (dump_stack+0xb0/0xe4)
[] (dump_stack) from [] (rpm_suspend+0x604/0x7e4)
[] (rpm_suspend) from [] (__pm_runtime_suspend+0x64/0x84)
[] (__pm_runtime_suspend) from [] (omap2_gpio_prepare_for_idle+0x5c/0x70)
[] (omap2_gpio_prepare_for_idle) from [] (omap_sram_idle+0x140/0x244)
[] (omap_sram_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec)
[] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4)
[] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0)
[] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8)
[] (start_kernel) from [<8000807c>] (0x8000807c)

------------------------------------------------------------------------

Reported-by: Tony Lindgren 
Signed-off-by: Paul E. McKenney 
Tested-by: Tony Lindgren 
Tested-by: Guenter Roeck 
[ rjw: Subject ]
Signed-off-by: Rafael J. Wysocki

PM / runtime: Add _rcuidle suffix to allow rpm_idle() use from idle

2016-08-31T01:00:59+00:00

This commit appends a few _rcuidle suffixes to fix the following
RCU-used-from-idle bug:

> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.6.0-rc5-next-20160426+ #1116 Not tainted
> -------------------------------
> include/trace/events/rpm.h:95 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 1 lock held by swapper/0/0:
>  #0:  (&(&dev->power.lock)->rlock){-.-...}, at: [] __rpm_callback+0x58/0x60
>
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1116
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xb0/0xe4)
> [] (dump_stack) from [] (rpm_suspend+0x580/0x768)
> [] (rpm_suspend) from [] (__pm_runtime_suspend+0x64/0x84)
> [] (__pm_runtime_suspend) from [] (omap2_gpio_prepare_for_idle+0x5c/0x70)
> [] (omap2_gpio_prepare_for_idle) from [] (omap_sram_idle+0x140/0x244)
> [] (omap_sram_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec)
> [] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4)
> [] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0)
> [] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8)
> [] (start_kernel) from [<8000807c>] (0x8000807c)

In the immortal words of Steven Rostedt, "*Whack* *Whack* *Whack*!!!"

Reported-by: Tony Lindgren 
Signed-off-by: Paul E. McKenney 
Tested-by: Tony Lindgren 
Tested-by: Guenter Roeck 
WhACKED-by: Steven Rostedt 
Signed-off-by: Rafael J. Wysocki

PM / runtime: Add _rcuidle suffix to allow rpm_resume() to be called from idle

2016-08-31T00:59:20+00:00

This commit applies another _rcuidle suffix to fix an RCU use from
idle.

> ===============================
> [ INFO: suspicious RCU usage. ]
> 4.6.0-rc5-next-20160426+ #1122 Not tainted
> -------------------------------
> include/trace/events/rpm.h:69 suspicious rcu_dereference_check() usage!
>
> other info that might help us debug this:
>
>
> RCU used illegally from idle CPU!
> rcu_scheduler_active = 1, debug_locks = 0
> RCU used illegally from extended quiescent state!
> 1 lock held by swapper/0/0:
>  #0:  (&(&dev->power.lock)->rlock){-.-...}, at: [] __pm_runtime_resume+0x3c/0x64
>
> stack backtrace:
> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.6.0-rc5-next-20160426+ #1122
> Hardware name: Generic OMAP36xx (Flattened Device Tree)
> [] (unwind_backtrace) from [] (show_stack+0x10/0x14)
> [] (show_stack) from [] (dump_stack+0xb0/0xe4)
> [] (dump_stack) from [] (rpm_resume+0x5cc/0x7f4)
> [] (rpm_resume) from [] (__pm_runtime_resume+0x4c/0x64)
> [] (__pm_runtime_resume) from [] (omap2_gpio_resume_after_idle+0x54/0x68)
> [] (omap2_gpio_resume_after_idle) from [] (omap3_enter_idle_bm+0xfc/0x1ec)
> [] (omap3_enter_idle_bm) from [] (cpuidle_enter_state+0x80/0x3d4)
> [] (cpuidle_enter_state) from [] (cpu_startup_entry+0x198/0x3a0)
> [] (cpu_startup_entry) from [] (start_kernel+0x354/0x3c8)
> [] (start_kernel) from [<8000807c>] (0x8000807c)

Reported-by: Tony Lindgren 
Signed-off-by: Paul E. McKenney 
Tested-by: Tony Lindgren 
Tested-by: Guenter Roeck 
Signed-off-by: Rafael J. Wysocki

Merge branches 'pm-core', 'pm-clk', 'pm-domains' and 'pm-pci'

2016-07-25T11:45:27+00:00

* pm-core:
  PM / runtime: Asynchronous "idle" in pm_runtime_allow()
  PM / runtime: print error when activating a child to unactive parent

* pm-clk:
  PM / clk: Add support for adding a specific clock from device-tree
  PM / clk: export symbols for existing pm_clk_<...> API fcns

* pm-domains:
  PM / Domains: Convert pm_genpd_init() to return an error code
  PM / Domains: Stop/start devices during system PM suspend/resume in genpd
  PM / Domains: Allow runtime PM during system PM phases
  PM / Runtime: Avoid resuming devices again in pm_runtime_force_resume()
  PM / Domains: Remove redundant pm_request_idle() call in genpd
  PM / Domains: Remove redundant wrapper functions for system PM
  PM / Domains: Allow genpd to power on during system PM phases

* pm-pci:
  PCI / PM: check all fields in pci_set_platform_pm()

PM / runtime: Asynchronous "idle" in pm_runtime_allow()

2016-07-01T23:50:39+00:00

Arjan reports that it takes a relatively long time to enable runtime
PM for multiple devices at system startup, because all writes to the
"control" attribute in sysfs are handled synchronously and if the
device is suspended as a result of the write, it will block until
that operation is complete.

That may be avoided by passing the RPM_ASYNC flag to rpm_idle()
in pm_runtime_allow() which will make it execute the device's
"idle" callback asynchronously, so writes to "control" changing
it from "on" to "auto" will return without waiting.

Reported-by: Arjan van de Ven 
Signed-off-by: Rafael J. Wysocki 
Acked-by: Alan Stern 
Reviewed-by: Ulf Hansson 
Reviewed-by: Kevin Hilman

PM / runtime: print error when activating a child to unactive parent

2016-06-27T22:40:30+00:00

The code currently silently bails out with -EBUSY if you try to
activate a child to an inactive parent.

This typically happens when you have a runtime suspended parent
and runtime resume your child, but forgot to set .ignore_children
on the parent to true with pm_suspend_ignore_children(dev).

Silently ignoring this error is not good as it gives rise to
other strange behaviour like double-resume of devices after
silently bailing out of the .runtime_resume() callback.

Signed-off-by: Linus Walleij 
Signed-off-by: Rafael J. Wysocki

PM / Runtime: Avoid resuming devices again in pm_runtime_force_resume()

2016-06-16T13:14:36+00:00

If the runtime PM status of the device isn't RPM_SUSPENDED, prevent the
pm_runtime_force_resume() from invoking the ->runtime_resume() callback
for the device, as it's not the expected behaviour from the subsystem/driver.

Signed-off-by: Ulf Hansson 
Reviewed-by: Kevin Hilman 
Signed-off-by: Rafael J. Wysocki

PM / Runtime: Fix error path in pm_runtime_force_resume()

2016-04-21T17:31:11+00:00

As pm_runtime_set_active() may fail because the device's parent isn't
active, we can end up executing the ->runtime_resume() callback for the
device when it isn't allowed.

Fix this by invoking pm_runtime_set_active() before running the callback
and let's also deal with the error code.

Fixes: 37f204164dfb (PM: Add pm_runtime_suspend|resume_force functions)
Signed-off-by: Ulf Hansson 
Reviewed-by: Linus Walleij 
Cc: 3.15+  # 3.15+
Signed-off-by: Rafael J. Wysocki