Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752727AbaBKG6I (ORCPT ); Tue, 11 Feb 2014 01:58:08 -0500 Received: from mx0b-0016f401.pphosted.com ([67.231.156.173]:2661 "EHLO mx0b-0016f401.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752211AbaBKG6F (ORCPT ); Tue, 11 Feb 2014 01:58:05 -0500 Message-ID: <52F9C95C.7050009@marvell.com> Date: Tue, 11 Feb 2014 14:55:24 +0800 From: Jane Li User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: , , 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 References: <52F5BFA3.2000306@marvell.com> <20140209154525.GI17001@phenom.ffwll.local> In-Reply-To: <20140209154525.GI17001@phenom.ffwll.local> Content-Type: text/plain; charset="us-ascii"; format=flowed Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87,1.0.14,0.0.0000 definitions=2014-02-11_03:2014-02-10,2014-02-11,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1305240000 definitions=main-1402100242 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/09/2014 11:45 PM, Daniel Vetter wrote: > 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 > Do same test as you suggested, there is no warning now. I have updated the patch named "printk: fix one circular lockdep warning about console_lock". Thanks! Best Regards, Jane -- 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/