Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755953Ab3I2T3M (ORCPT ); Sun, 29 Sep 2013 15:29:12 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:59651 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755924Ab3I2T3G (ORCPT ); Sun, 29 Sep 2013 15:29:06 -0400 From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Thomas Gleixner , =?UTF-8?q?Ville=20Syrj=C3=A4l=C3=A4?= , Chris Wilson , Daniel Vetter Subject: [ 24/71] drm/i915: fix gpu hang vs. flip stall deadlocks Date: Sun, 29 Sep 2013 12:27:36 -0700 Message-Id: <20130929192645.172413948@linuxfoundation.org> X-Mailer: git-send-email 1.8.4.6.g82e253f.dirty In-Reply-To: <20130929192643.539596256@linuxfoundation.org> References: <20130929192643.539596256@linuxfoundation.org> User-Agent: quilt/0.60-1 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5746 Lines: 128 3.11-stable review patch. If anyone has any objections, please let me know. ------------------ From: Daniel Vetter commit 122f46badaafbe651f05c2c0f24cadee692f761b upstream. Since we've started to clean up pending flips when the gpu hangs in commit 96a02917a0131e52efefde49c2784c0421d6c439 Author: Ville Syrjälä Date: Mon Feb 18 19:08:49 2013 +0200 drm/i915: Finish page flips and update primary planes after a GPU reset the gpu reset work now also grabs modeset locks. But since work items on our private work queue are not allowed to do that due to the flush_workqueue from the pageflip code this results in a neat deadlock: INFO: task kms_flip:14676 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kms_flip D ffff88019283a5c0 0 14676 13344 0x00000004 ffff88018e62dbf8 0000000000000046 ffff88013bdb12e0 ffff88018e62dfd8 ffff88018e62dfd8 00000000001d3b00 ffff88019283a5c0 ffff88018ec21000 ffff88018f693f00 ffff88018eece000 ffff88018e62dd60 ffff88018eece898 Call Trace: [] schedule+0x60/0x62 [] intel_crtc_wait_for_pending_flips+0xb2/0x114 [i915] [] ? finish_wait+0x60/0x60 [] intel_crtc_set_config+0x7f3/0x81e [i915] [] drm_mode_set_config_internal+0x4f/0xc6 [drm] [] drm_mode_setcrtc+0x44d/0x4f9 [drm] [] ? might_fault+0x38/0x86 [] drm_ioctl+0x2f9/0x447 [drm] [] ? trace_hardirqs_off+0xd/0xf [] ? drm_mode_setplane+0x343/0x343 [drm] [] ? mntput_no_expire+0x3e/0x13d [] vfs_ioctl+0x18/0x34 [] do_vfs_ioctl+0x396/0x454 [] ? sysret_check+0x1b/0x56 [] SyS_ioctl+0x52/0x7d [] system_call_fastpath+0x16/0x1b 2 locks held by kms_flip/14676: #0: (&dev->mode_config.mutex){+.+.+.}, at: [] drm_modeset_lock_all+0x22/0x59 [drm] #1: (&crtc->mutex){+.+.+.}, at: [] drm_modeset_lock_all+0x48/0x59 [drm] INFO: task kworker/u8:4:175 blocked for more than 120 seconds. "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. kworker/u8:4 D ffff88018de9a5c0 0 175 2 0x00000000 Workqueue: i915 i915_error_work_func [i915] ffff88018e37dc30 0000000000000046 ffff8801938ab8a0 ffff88018e37dfd8 ffff88018e37dfd8 00000000001d3b00 ffff88018de9a5c0 ffff88018ec21018 0000000000000246 ffff88018e37dca0 000000005a865a86 ffff88018de9a5c0 Call Trace: [] schedule+0x60/0x62 [] schedule_preempt_disabled+0x9/0xb [] mutex_lock_nested+0x205/0x3b1 [] ? intel_display_handle_reset+0x7e/0xbd [i915] [] ? intel_display_handle_reset+0x7e/0xbd [i915] [] intel_display_handle_reset+0x7e/0xbd [i915] [] i915_error_work_func+0x128/0x147 [i915] [] process_one_work+0x1d4/0x35a [] ? process_one_work+0x15b/0x35a [] worker_thread+0x144/0x1f0 [] ? rescuer_thread+0x275/0x275 [] kthread+0xac/0xb4 [] ? finish_task_switch+0x3b/0xc0 [] ? __kthread_parkme+0x60/0x60 [] ret_from_fork+0x7c/0xb0 [] ? __kthread_parkme+0x60/0x60 3 locks held by kworker/u8:4/175: #0: (i915){.+.+.+}, at: [] process_one_work+0x15b/0x35a #1: ((&dev_priv->gpu_error.work)){+.+.+.}, at: [] process_one_work+0x15b/0x35a #2: (&crtc->mutex){+.+.+.}, at: [] intel_display_handle_reset+0x7e/0xbd [i915] This blew up while running kms_flip/flip-vs-panning-vs-hang-interruptible on one of my older machines. Unfortunately (despite the proper lockdep annotations for flush_workqueue) lockdep still doesn't detect this correctly, so we need to rely on chance to discover these bugs. Apply the usual bugfix and schedule the reset work on the system workqueue to keep our own driver workqueue free of any modeset lock grabbing. Note that this is not a terribly serious regression since before the offending commit we'd simply have stalled userspace forever due to failing to abort all outstanding pageflips. v2: Add a comment as requested by Chris. Cc: Thomas Gleixner Cc: Ville Syrjälä Cc: Chris Wilson Reviewed-by: Chris Wilson Signed-off-by: Daniel Vetter Signed-off-by: Greg Kroah-Hartman --- drivers/gpu/drm/i915/i915_irq.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -2127,7 +2127,13 @@ void i915_handle_error(struct drm_device wake_up_all(&ring->irq_queue); } - queue_work(dev_priv->wq, &dev_priv->gpu_error.work); + /* + * Our reset work can grab modeset locks (since it needs to reset the + * state of outstanding pagelips). Hence it must not be run on our own + * dev-priv->wq work queue for otherwise the flush_work in the pageflip + * code will deadlock. + */ + schedule_work(&dev_priv->gpu_error.work); } static void __always_unused i915_pageflip_stall_check(struct drm_device *dev, int pipe) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/