Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751775AbaBIPpd (ORCPT ); Sun, 9 Feb 2014 10:45:33 -0500 Received: from mail-ea0-f172.google.com ([209.85.215.172]:48039 "EHLO mail-ea0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751424AbaBIPpb (ORCPT ); Sun, 9 Feb 2014 10:45:31 -0500 Date: Sun, 9 Feb 2014 16:45:25 +0100 From: Daniel Vetter To: Jane Li Cc: tianxf@marvell.com, fswu@marvell.com, Toshi Kani , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Andrew Morton , Linux Kernel Mailing List , Joe Perches , Tejun Heo Subject: Re: Question about console_lock lockdep after involving console_lock_dep_map Message-ID: <20140209154525.GI17001@phenom.ffwll.local> Mail-Followup-To: Jane Li , tianxf@marvell.com, fswu@marvell.com, Toshi Kani , Ingo Molnar , Peter Zijlstra , Thomas Gleixner , Andrew Morton , Linux Kernel Mailing List , Joe Perches , Tejun Heo References: <52F5BFA3.2000306@marvell.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <52F5BFA3.2000306@marvell.com> X-Originating-IP: [84.73.67.144] User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Adding many more people and lkml to the cc list. Please don't poke people in private, but always cc a relevant mailing list. On Sat, Feb 8, 2014 at 6:24 AM, Jane Li wrote: > Hi Danial Vetter, > > I found you had added console_lock_dep_map in commit daee7797 (console: > implement lockdep support for console_lock). I encounter another circular > lock warning related to it. > > Sequence: > > enter suspend -> resume -> plug-out CPUx (echo 0 > cpux/online) > > Then, lockdep will show warning as following: > > ====================================================== > [ INFO: possible circular locking dependency detected ] > 3.10.0 #2 Tainted: G O > ------------------------------------------------------- > sh/1271 is trying to acquire lock: > (console_lock){+.+.+.}, at: [] console_cpu_notify+0x20/0x2c > but task is already holding lock: > (cpu_hotplug.lock){+.+.+.}, at: [] cpu_hotplug_begin+0x2c/0x58 > which lock already depends on the new lock. > > the existing dependency chain (in reverse order) is: > -> #2 (cpu_hotplug.lock){+.+.+.}: > [] lock_acquire+0x98/0x12c > [] mutex_lock_nested+0x50/0x3d8 > [] cpu_hotplug_begin+0x2c/0x58 > [] _cpu_up+0x24/0x154 > [] cpu_up+0x64/0x84 > [] smp_init+0x9c/0xd4 > [] kernel_init_freeable+0x78/0x1c8 > [] kernel_init+0x8/0xe4 > [] ret_from_fork+0x14/0x2c > > -> #1 (cpu_add_remove_lock){+.+.+.}: > [] lock_acquire+0x98/0x12c > [] mutex_lock_nested+0x50/0x3d8 > [] disable_nonboot_cpus+0x8/0xe8 > [] suspend_devices_and_enter+0x214/0x448 > [] pm_suspend+0x1e4/0x284 > [] try_to_suspend+0xa4/0xbc > [] process_one_work+0x1c4/0x4fc > [] worker_thread+0x138/0x37c > [] kthread+0xa4/0xb0 > [] ret_from_fork+0x14/0x2c > > -> #0 (console_lock){+.+.+.}: > [] __lock_acquire+0x1b38/0x1b80 > [] lock_acquire+0x98/0x12c > [] console_lock+0x54/0x68 > [] console_cpu_notify+0x20/0x2c > [] notifier_call_chain+0x44/0x84 > [] __cpu_notify+0x2c/0x48 > [] cpu_notify_nofail+0x8/0x14 > [] _cpu_down+0xf4/0x258 > [] cpu_down+0x24/0x40 > [] store_online+0x30/0x74 > [] dev_attr_store+0x18/0x24 > [] sysfs_write_file+0x16c/0x19c > [] vfs_write+0xb4/0x190 > [] SyS_write+0x3c/0x70 > [] ret_fastChain exists of: > console_lock --> cpu_add_remove_lock --> cpu_hotplug.lock > > Possible unsafe locking scenario: > CPU0 CPU1 > ---- ---- > lock(cpu_hotplug.lock); > lock(cpu_add_remove_lock); > lock(cpu_hotplug.lock); > lock(console_lock); > *** DEADLOCK *** > > > > Analyze this information, there are three locks involved in two sequence: > > pm suspend: console_lock (@suspend_console()) -> cpu_add_remove_lock > (@disable_nonboot_cpus()) -> cpu_hotplug.lock (@_cpu_down()) > > Plug-out CPUx: cpu_add_remove_lock (@(cpu_down()) -> > cpu_hotplug.lock (@_cpu_down()) -> console_lock (@console_cpu_notify()) => > Lockdeps prints warning log. > > > I check code and there should be not real deadlock, as flag of > console_suspended can protect this. > > Do you know how to avoid this warning? I think the right approach here is to add a new function to do the console flushing: /** * console_flush - flush dmesg if console isn't suspended * * console_unlock always flushes the dmesg buffer, so just try to * grab&drop the console lock. If that fails we know that the current * holder will eventually drop the console lock and so flush the dmesg * buffers at the earliest possible time. */ void console_flush(void) { if (console_trylock()) console_unlock(); } Then use that instead of the unconditional console_lock/unlock pair int the console_cpu_notitifier. Since that's practically the patch already feel free to smash a Signed-off-by: Daniel Vetter on top if it works. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- 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/