[PATCH] drm: Don't allow interruptions when opening debugfs/crc

Chris Wilson chris at chris-wilson.co.uk
Fri Apr 7 18:35:06 UTC 2017


On Fri, Apr 07, 2017 at 06:42:46PM +0200, Daniel Vetter wrote:
> On Fri, Apr 07, 2017 at 01:55:00PM +0200, Tomeu Vizoso wrote:
> > On 04/07/2017 01:17 PM, Chris Wilson wrote:
> > > The code does not like to be interrupted when waiting for the first
> > > vblank after opening a debugfs/crc channel, so don't.
> > > 
> > > [66285.716870] WARNING: CPU: 1 PID: 16615 at drivers/gpu/drm/drm_debugfs_crc.c:185 crtc_crc_open+0x1d0/0x1f0 [drm]
> > > [66285.716877] Modules linked in: i915 intel_powerclamp crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel cryptd intel_gtt i2c_algo_bit lpc_ich mfd_core drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops prime_numbers drm video button autofs4 sd_mod ahci libahci libata i2c_i801 scsi_mod i2c_designware_platform i2c_designware_core i2c_core
> > > [66285.716929] CPU: 1 PID: 16615 Comm: kms_frontbuffer Not tainted 4.11.0-rc5+ #7
> > > [66285.716935] Hardware name: GIGABYTE GB-BXBT-1900/MZBAYAB-00, BIOS F8 03/02/2016
> > > [66285.716941] Call Trace:
> > > [66285.716955]  dump_stack+0x4d/0x6f
> > > [66285.716966]  __warn+0xc1/0xe0
> > > [66285.716975]  warn_slowpath_null+0x18/0x20
> > > [66285.717004]  crtc_crc_open+0x1d0/0x1f0 [drm]
> > > [66285.717014]  ? wake_atomic_t_function+0x50/0x50
> > > [66285.717024]  full_proxy_open+0xf0/0x1b0
> > > [66285.717032]  ? full_proxy_release+0x80/0x80
> > > [66285.717042]  do_dentry_open.isra.17+0x14b/0x2d0
> > > [66285.717051]  vfs_open+0x42/0x60
> > > [66285.717064]  path_openat+0x5e7/0x13d0
> > > [66285.717074]  ? refcount_dec_and_test+0x11/0x20
> > > [66285.717081]  ? down_read+0xd/0x30
> > > [66285.717087]  do_filp_open+0x85/0xf0
> > > [66285.717093]  ? __vfs_write+0x23/0x120
> > > [66285.717100]  ? __alloc_fd+0x3a/0x170
> > > [66285.717107]  do_sys_open+0x11e/0x1f0
> > > [66285.717113]  ? do_sys_open+0x11e/0x1f0
> > > [66285.717119]  SyS_openat+0xf/0x20
> > > [66285.717125]  entry_SYSCALL_64_fastpath+0x17/0x98
> > > [66285.717131] RIP: 0033:0x7f5f2235146a
> > > [66285.717135] RSP: 002b:00007ffd892e6bc0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
> > > [66285.717142] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007f5f2235146a
> > > [66285.717147] RDX: 0000000000000000 RSI: 00007ffd892e6c40 RDI: 0000000000000006
> > > [66285.717151] RBP: 00007ffd892e6b20 R08: 0000000000000000 R09: 000000000000000f
> > > [66285.717156] R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000001
> > > [66285.717161] R13: 00007ffd892e6b10 R14: 0000000000000004 R15: 00000000007e61f4
> > > 
> > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100610
> > > Fixes: e8fa5671183c ("drm: crc: Wait for a frame before returning from open()")
> > > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > > Cc: Tomeu Vizoso <tomeu.vizoso at collabora.com>
> > > Cc: Daniel Vetter <daniel.vetter at ffwll.ch>
> > 
> > Reviewed-by: Tomeu Vizoso <tomeu.vizoso at collabora.com>
> > 
> > Sounds good to me, there isn't any good reason for the wait to be
> > interruptible.
> 
> Applied to drm-misc-next, thanks.

Oh no. The other side is using wake_up_interruptible(), so only the
interruptible waiters are woken and not us anymore :(

diff --git a/drivers/gpu/drm/drm_debugfs_crc.c b/drivers/gpu/drm/drm_debugfs_crc.c
index aa13e734c9e5..1ec04f864437 100644
--- a/drivers/gpu/drm/drm_debugfs_crc.c
+++ b/drivers/gpu/drm/drm_debugfs_crc.c
@@ -354,7 +354,7 @@ int drm_crtc_add_crc_entry(struct drm_crtc *crtc, bool has_frame,
 
        spin_unlock(&crc->lock);
 
-       wake_up_interruptible(&crc->wq);
+       wake_up(&crc->wq);
 
        return 0;
 }

Undoes the damage, or revert?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre


More information about the dri-devel mailing list