Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752135AbcC3Jyf (ORCPT ); Wed, 30 Mar 2016 05:54:35 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:35320 "EHLO mail-wm0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752419AbcC3Jyc (ORCPT ); Wed, 30 Mar 2016 05:54:32 -0400 Date: Wed, 30 Mar 2016 11:54:34 +0200 From: Daniel Vetter To: =?iso-8859-1?Q?Bj=F8rn?= Mork Cc: Daniel Vetter , David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [Intel-gfx] [PATCH] drm/i915: fix deadlock on lid open Message-ID: <20160330095434.GD2510@phenom.ffwll.local> Mail-Followup-To: =?iso-8859-1?Q?Bj=F8rn?= Mork , Daniel Vetter , David Airlie , intel-gfx@lists.freedesktop.org, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org References: <1459328913-13719-1-git-send-email-bjorn@mork.no> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1459328913-13719-1-git-send-email-bjorn@mork.no> X-Operating-System: Linux phenom 4.4.0-1-amd64 User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5519 Lines: 123 On Wed, Mar 30, 2016 at 11:08:33AM +0200, Bj?rn Mork wrote: > commit e2c8b8701e2d moved modeset locking inside resume/suspend > functions, but missed a code path only executed on lid close/open > on older hardware. The result was a deadlock when closing and > opening the lid without suspending on such hardware: > > ============================================= > [ INFO: possible recursive locking detected ] > 4.6.0-rc1 #385 Not tainted > --------------------------------------------- > kworker/0:3/88 is trying to acquire lock: > (&dev->mode_config.mutex){+.+.+.}, at: [] intel_display_resume+0x4a/0x12f [i915] > > but task is already holding lock: > (&dev->mode_config.mutex){+.+.+.}, at: [] drm_modeset_lock_all+0x3e/0xa6 [drm] > > other info that might help us debug this: > Possible unsafe locking scenario: > > CPU0 > ---- > lock(&dev->mode_config.mutex); > lock(&dev->mode_config.mutex); > > *** DEADLOCK *** > > May be due to missing lock nesting notation > > 7 locks held by kworker/0:3/88: > #0: ("kacpi_notify"){++++.+}, at: [] process_one_work+0x14a/0x50b > #1: ((&dpc->work)#2){+.+.+.}, at: [] process_one_work+0x14a/0x50b > #2: ((acpi_lid_notifier).rwsem){++++.+}, at: [] __blocking_notifier_call_chain+0x34/0x65 > #3: (&dev_priv->modeset_restore_lock){+.+.+.}, at: [] intel_lid_notify+0x3c/0xd9 [i915] > #4: (&dev->mode_config.mutex){+.+.+.}, at: [] drm_modeset_lock_all+0x3e/0xa6 [drm] > #5: (crtc_ww_class_acquire){+.+.+.}, at: [] drm_modeset_lock_all+0x48/0xa6 [drm] > #6: (crtc_ww_class_mutex){+.+.+.}, at: [] modeset_lock+0x13c/0x1cd [drm] > > stack backtrace: > CPU: 0 PID: 88 Comm: kworker/0:3 Not tainted 4.6.0-rc1 #385 > Hardware name: LENOVO 2776LEG/2776LEG, BIOS 6EET55WW (3.15 ) 12/19/2011 > Workqueue: kacpi_notify acpi_os_execute_deferred > 0000000000000000 ffff88022fd5f990 ffffffff8124af06 ffffffff825b39c0 > ffffffff825b39c0 ffff88022fd5fa60 ffffffff8108f547 ffff88022fd5fa70 > 000000008108e817 ffff880230236cc0 0000000000000000 ffffffff825b39c0 > Call Trace: > [] dump_stack+0x67/0x90 > [] __lock_acquire+0xdb5/0xf71 > [] ? look_up_lock_class+0xbe/0x10a > [] lock_acquire+0x137/0x1cb > [] ? lock_acquire+0x137/0x1cb > [] ? intel_display_resume+0x4a/0x12f [i915] > [] mutex_lock_nested+0x7e/0x3a4 > [] ? intel_display_resume+0x4a/0x12f [i915] > [] ? intel_display_resume+0x4a/0x12f [i915] > [] ? modeset_lock+0x13c/0x1cd [drm] > [] intel_display_resume+0x4a/0x12f [i915] > [] ? intel_display_resume+0x4a/0x12f [i915] > [] ? modeset_lock+0x13c/0x1cd [drm] > [] ? modeset_lock+0x13c/0x1cd [drm] > [] ? drm_modeset_lock+0x17/0x24 [drm] > [] ? drm_modeset_lock_all_ctx+0x87/0xa1 [drm] > [] intel_lid_notify+0xb0/0xd9 [i915] > [] notifier_call_chain+0x4a/0x6c > [] __blocking_notifier_call_chain+0x4d/0x65 > [] blocking_notifier_call_chain+0x14/0x16 > [] acpi_lid_send_state+0x83/0xad [button] > [] acpi_button_notify+0x41/0x132 [button] > [] acpi_device_notify+0x19/0x1b > [] acpi_ev_notify_dispatch+0x49/0x64 > [] acpi_os_execute_deferred+0x14/0x20 > [] process_one_work+0x265/0x50b > [] worker_thread+0x1fc/0x2dd > [] ? rescuer_thread+0x309/0x309 > [] ? rescuer_thread+0x309/0x309 > [] kthread+0xe0/0xe8 > [] ? local_clock+0x19/0x22 > [] ret_from_fork+0x22/0x40 > [] ? kthread_create_on_node+0x1b5/0x1b5 > > Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") > Cc: Maarten Lankhorst > Signed-off-by: Bj?rn Mork Oops, that one's pretty silly. Unfortunately we don't have any such machines in CI yet, and it wouldn't be possible to exercise the lid notifier automatically. Thanks for your fix, applied. -Daniel > --- > drivers/gpu/drm/i915/intel_lvds.c | 5 +---- > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_lvds.c b/drivers/gpu/drm/i915/intel_lvds.c > index 30a8403a8f4f..cd9fe609aefb 100644 > --- a/drivers/gpu/drm/i915/intel_lvds.c > +++ b/drivers/gpu/drm/i915/intel_lvds.c > @@ -478,11 +478,8 @@ static int intel_lid_notify(struct notifier_block *nb, unsigned long val, > * and as part of the cleanup in the hw state restore we also redisable > * the vga plane. > */ > - if (!HAS_PCH_SPLIT(dev)) { > - drm_modeset_lock_all(dev); > + if (!HAS_PCH_SPLIT(dev)) > intel_display_resume(dev); > - drm_modeset_unlock_all(dev); > - } > > dev_priv->modeset_restore = MODESET_DONE; > > -- > 2.1.4 > > _______________________________________________ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch