diff mbox

[v3,09/10] drm/i915/psr: Set DPCD PSR2 enable bit when needed

Message ID 152292198376.23264.11044181545234782174@mail.alporthouse.com (mailing list archive)
State New, archived
Headers show

Commit Message

Chris Wilson April 5, 2018, 9:53 a.m. UTC 
Quoting Rodrigo Vivi (2018-03-30 18:41:08)
> On Wed, Mar 28, 2018 at 03:30:45PM -0700, José Roberto de Souza wrote:
> > In the 2 eDP1.4a pannels tested set or not set bit have no effect
> > but is better set it and comply with specification.
> > 
> > Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
> > Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
> > Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
> 
> patches 1-9 pushed to dinq. Thanks for patches and reviews.

Might be coincidental, but this GPF hasn't occurred before:

https://intel-gfx-ci.01.org/tree/drm-tip/kasan_26/fi-cfl-s3/dmesg15.log
<7>[   40.159658] [drm:intel_enable_sagv [i915]] Enabling the SAGV
<0>[   40.162715] kasan: CONFIG_KASAN_INLINE enabled
<0>[   40.162884] kasan: GPF could be caused by NULL-ptr deref or user memory access
<4>[   40.162910] general protection fault: 0000 [#1] PREEMPT SMP KASAN PTI
<4>[   40.179985] Modules linked in: i915 cdc_ether usbnet x86_pkg_temp_thermal r8152 intel_powerclamp mii coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel e1000e mei_me mei prime_numbers
<4>[   40.180000] CPU: 9 PID: 1395 Comm: kms_color Tainted: G     U           4.16.0-rc7-g29940f138482-kasan_26+ #1
<4>[   40.180002] Hardware name: Intel Corporation CoffeeLake Client Platform/CoffeeLake S UDIMM RVP, BIOS CNLSFWR1.R00.X118.B19.1802080131 02/08/2018
<4>[   40.180055] RIP: 0010:intel_psr_flush+0x140/0x4b0 [i915]
<4>[   40.180057] RSP: 0018:ffff880404fd7818 EFLAGS: 00010202
<4>[   40.180060] RAX: dffffc0000000000 RBX: ffff8803b4820000 RCX: 0000000000000000
<4>[   40.180062] RDX: 00000000000000bc RSI: 0000000000000000 RDI: 00000000000005e0
<4>[   40.180076] RBP: ffff8803b482a5d8 R08: ffffffff8b02b360 R09: ffffffff8a32df20
<4>[   40.180078] R10: ffff880404fd7818 R11: 0000000000000000 R12: 0000000000000100
<4>[   40.180079] R13: 0000000000000000 R14: 0000000000000100 R15: 0000000000000000
<4>[   40.180081] FS:  00007ff255bfe980(0000) GS:ffff88041dc40000(0000) knlGS:0000000000000000
<4>[   40.180083] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
<4>[   40.180085] CR2: 00007fdf372522f8 CR3: 0000000419d9a005 CR4: 00000000003606e0
<4>[   40.180086] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
<4>[   40.180088] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
<4>[   40.180089] Call Trace:
<4>[   40.180125]  intel_frontbuffer_flush+0x8e/0xb0 [i915]
<4>[   40.180161]  intel_prepare_plane_fb+0x699/0xb20 [i915]
<4>[   40.180167]  drm_atomic_helper_prepare_planes+0x118/0x480
<4>[   40.180202]  ? haswell_crtc_compute_clock+0xc4/0xc4 [i915]
<4>[   40.180237]  intel_atomic_commit+0x215/0xcd0 [i915]
<4>[   40.180242]  set_property_atomic+0x1d5/0x250
<4>[   40.180245]  ? drm_object_property_get_value+0xe0/0xe0
<4>[   40.180251]  drm_mode_obj_set_property_ioctl+0x334/0x5b0
<4>[   40.180254]  ? drm_mode_obj_find_prop_id+0x180/0x180
<4>[   40.180257]  ? drm_is_current_master+0x5a/0x100
<4>[   40.180260]  ? drm_mode_obj_find_prop_id+0x180/0x180
<4>[   40.180262]  drm_ioctl_kernel+0x189/0x200
<4>[   40.180265]  ? drm_ioctl_permit+0x2b0/0x2b0
<4>[   40.180269]  drm_ioctl+0x662/0x880
<4>[   40.180272]  ? drm_mode_obj_find_prop_id+0x180/0x180
<4>[   40.180274]  ? drm_getstats+0x20/0x20
<4>[   40.180277]  ? lock_acquire+0x390/0x390
<4>[   40.180281]  ? debug_check_no_locks_freed+0x270/0x270
<4>[   40.180284]  ? __might_fault+0xea/0x1a0
<4>[   40.180288]  do_vfs_ioctl+0x171/0xe50
<4>[   40.180292]  ? ioctl_preallocate+0x170/0x170
<4>[   40.180295]  ? __task_pid_nr_ns+0x17b/0x3d0
<4>[   40.180298]  ? lock_acquire+0x390/0x390
<4>[   40.180302]  SyS_ioctl+0x36/0x70
<4>[   40.180304]  ? do_vfs_ioctl+0xe50/0xe50
<4>[   40.180307]  do_syscall_64+0x18a/0x5c0
<4>[   40.180311]  entry_SYSCALL_64_after_hwframe+0x42/0xb7
<4>[   40.180313] RIP: 0033:0x7ff254cf65d7
<4>[   40.180315] RSP: 002b:00007ffc2f0fca58 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
<4>[   40.180317] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007ff254cf65d7
<4>[   40.180319] RDX: 00007ffc2f0fca90 RSI: 00000000c01864ba RDI: 0000000000000003
<4>[   40.180321] RBP: 00007ffc2f0fca90 R08: 0000000000000001 R09: 0000000000000000
<4>[   40.180322] R10: 000055be9798e010 R11: 0000000000000246 R12: 00000000c01864ba
<4>[   40.180324] R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
<4>[   40.180328] Code: ea 03 80 3c 02 00 0f 85 4c 03 00 00 4d 8b ad 48 ff ff ff 48 b8 00 00 00 00 00 fc ff df 49 8d bd e0 05 00 00 48 89 fa 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e ee 01 00 00 4d 63 ad e0 05 
<1>[   40.180402] RIP: intel_psr_flush+0x140/0x4b0 [i915] RSP: ffff880404fd7818
<4>[   40.180416] ---[ end trace 53653c4618c4b0b4 ]---

A null pointer in intel_psr_flush, probably crtc?

The code where we case the psr.enabled in the intel_psr_work preamble is
unlocked, and we do race there with intel_psr_disable() setting it to NULL
before cancelling the work. E.g.


Haven't spotted the chain of events that leads to intel_psr_flush()
crashing though.
-Chris
diff mbox

Patch

diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 2d53f7398a6d..c0a7295920dd 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -758,6 +758,8 @@  void intel_psr_disable(struct intel_dp *intel_dp,
        if (WARN_ON(!CAN_PSR(dev_priv)))
                return;
 
+       cancel_delayed_work_sync(&dev_priv->psr.work);
+
        mutex_lock(&dev_priv->psr.lock);
        if (!dev_priv->psr.enabled) {
                mutex_unlock(&dev_priv->psr.lock);
@@ -771,8 +773,6 @@  void intel_psr_disable(struct intel_dp *intel_dp,
 
        dev_priv->psr.enabled = NULL;
        mutex_unlock(&dev_priv->psr.lock);
-
-       cancel_delayed_work_sync(&dev_priv->psr.work);
 }
 
 static void intel_psr_work(struct work_struct *work)