Bug 89166 - [ivb] mutex deadlock
Summary: [ivb] mutex deadlock
Status: CLOSED FIXED
Alias: None
Product: DRI
Classification: Unclassified
Component: DRM/Intel (show other bugs)
Version: DRI git
Hardware: Other All
: medium blocker
Assignee: Tvrtko Ursulin
QA Contact: Intel GFX Bugs mailing list
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-16 13:30 UTC by Chris Wilson
Modified: 2017-07-24 22:48 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
Eugh, this is ugly. (3.04 KB, patch)
2015-02-16 13:39 UTC, Chris Wilson
no flags Details | Splinter Review
Still ugly (4.32 KB, patch)
2015-02-16 14:04 UTC, Chris Wilson
no flags Details | Splinter Review

Description Chris Wilson 2015-02-16 13:30:21 UTC
[  600.562671] INFO: task kworker/u32:5:99 blocked for more than 120 seconds.
[  600.562691]       Not tainted 3.19.0+ #251
[  600.562694] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[  600.562697] kworker/u32:5   D ffff88009c183c98     0    99      2 0x00000000
[  600.562710] Workqueue: i915 intel_unpin_work_fn
[  600.562716]  ffff88009c183c98 ffff8802561c4010 ffff88009c122010 ffff88009c183c68
[  600.562726]  ffffffff8157c84e ffff88009c183cc8 ffff88009c183fd8 ffff880255bef864
[  600.562736]  ffff88009c122010 00000000ffffffff ffff880255bef868 ffff88009c183cb8
[  600.562746] Call Trace:
[  600.562753]  [<ffffffff8157c84e>] ? schedule_preempt_disabled+0xe/0x10
[  600.562760]  [<ffffffff8157c787>] schedule+0x37/0x90
[  600.562765]  [<ffffffff8157c84e>] schedule_preempt_disabled+0xe/0x10
[  600.562769]  [<ffffffff8157e553>] __mutex_lock_slowpath+0x93/0x100
[  600.562773]  [<ffffffff8157e5db>] mutex_lock+0x1b/0x30
[  600.562778]  [<ffffffff813d5a73>] intel_user_framebuffer_destroy+0x23/0xa0
[  600.562783]  [<ffffffff8135e58e>] drm_framebuffer_free+0x4e/0x60
[  600.562788]  [<ffffffff8135eed5>] drm_framebuffer_unreference+0x35/0x70
[  600.562792]  [<ffffffff813d62e8>] intel_unpin_work_fn+0x68/0x150
[  600.562797]  [<ffffffff810a054d>] process_one_work+0x14d/0x410
[  600.562802]  [<ffffffff810a087b>] worker_thread+0x6b/0x470
[  600.562806]  [<ffffffff810a0810>] ? process_one_work+0x410/0x410
[  600.562810]  [<ffffffff810a5e2b>] kthread+0xdb/0x100
[  600.562814]  [<ffffffff810a5d50>] ? __kthread_parkme+0x90/0x90
[  600.562818]  [<ffffffff815805ac>] ret_from_fork+0x7c/0xb0
[  600.562822]  [<ffffffff810a5d50>] ? __kthread_parkme+0x90/0x90
Comment 1 Chris Wilson 2015-02-16 13:39:49 UTC
Created attachment 113531 [details] [review]
Eugh, this is ugly.
Comment 2 Chris Wilson 2015-02-16 13:46:14 UTC
Regression from commit ab8d66752a9c28cd6c94fa173feacdfc1554aa03
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date:   Mon Feb 2 15:44:15 2015 +0000

    drm/i915: Track old framebuffer instead of object
Comment 3 Chris Wilson 2015-02-16 13:51:45 UTC
update_state_fb() still holds the struct_mutex in almost all instances and looks pretty hard to extract.
Comment 4 Chris Wilson 2015-02-16 13:53:35 UTC
The other culprit is

commit 60a5ca015ffd2aacfe5674b5a401cd2a37159e07
Author: Ville Syrjälä <ville.syrjala@linux.intel.com>
Date:   Fri Jun 13 11:10:53 2014 +0300

    drm/i915: Add locking around framebuffer_references--
Comment 5 Chris Wilson 2015-02-16 14:04:33 UTC
Created attachment 113537 [details] [review]
Still ugly
Comment 6 Tvrtko Ursulin 2015-02-17 10:44:50 UTC
Could simply revert the culprit? It looked like it would be needed but the direction has changes since then so I am pretty sure it wouldn't affect anything.
Comment 7 Jani Nikula 2015-04-14 13:02:07 UTC
commit e0d6149b3debce1a7e17dfda7c2829935917dc58
Author: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Date:   Mon Apr 13 16:03:03 2015 +0100

    drm/i915: Move drm_framebuffer_unreference out of struct_mutex for takeover


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.