linux-stable/drivers/base/power
Rafael J. Wysocki a9306a6363 PM / runtime: Avoid false-positive warnings from might_sleep_if()
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:
  [<ffffffffa0680c13>] 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 <sedat.dilek@gmail.com>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
2017-02-04 00:44:36 +01:00
..
opp PM / OPP: Don't WARN on multiple calls to dev_pm_opp_set_regulators() 2016-12-06 02:28:00 +01:00
clock_ops.c PM / clk: Add support for adding a specific clock from device-tree 2016-06-28 00:42:10 +02:00
common.c PM: Avoid false-positive warnings in dev_pm_domain_set() 2016-02-03 19:10:37 +01:00
domain.c PM / domains: Fix 'may be used uninitialized' build warning 2016-12-31 21:52:07 +01:00
domain_governor.c PM / Domains: Rename stop_ok to suspend_ok for the genpd governor 2016-04-22 02:29:17 +02:00
generic_ops.c PM / PCI / ACPI: Kick devices that might have been reset by firmware 2015-10-14 02:17:34 +02:00
main.c ktime: Cleanup ktime_set() usage 2016-12-25 17:21:22 +01:00
Makefile PM / OPP: Move opp core to its own directory 2015-09-15 02:03:16 +02:00
power.h Driver core patches for 4.10-rc1 2016-12-13 11:42:18 -08:00
qos.c PM / QoS: Export dev_pm_qos_update_user_latency_tolerance 2016-11-30 22:34:24 +01:00
runtime.c PM / runtime: Avoid false-positive warnings from might_sleep_if() 2017-02-04 00:44:36 +01:00
sysfs.c PM / QoS: Improve sysfs pm_qos_latency_tolerance validation 2016-11-30 22:34:23 +01:00
trace.c timekeeping: Ignore the bogus sleep time if pm_trace is enabled 2016-11-29 18:02:58 +01:00
wakeirq.c PM / wakeirq: Fix dedicated wakeirq for drivers not using autosuspend 2016-12-06 23:45:59 +01:00
wakeup.c ktime: Cleanup ktime_set() usage 2016-12-25 17:21:22 +01:00