From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx137.postini.com [74.125.245.137]) by kanga.kvack.org (Postfix) with SMTP id 142FB6B005D for ; Thu, 18 Oct 2012 08:26:12 -0400 (EDT) Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 18 Oct 2012 06:26:07 -0600 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by d03dlp01.boulder.ibm.com (Postfix) with ESMTP id BDD8E1FF0054 for ; Thu, 18 Oct 2012 06:24:46 -0600 (MDT) Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q9ICOkG2245550 for ; Thu, 18 Oct 2012 06:24:46 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q9ICOj70009677 for ; Thu, 18 Oct 2012 06:24:46 -0600 Date: Thu, 18 Oct 2012 20:24:17 +0800 From: Gavin Shan Subject: Re: mm/mmu_notifier: inconsistent lock state in mmu_notifier_register() Message-ID: <20121018122416.GA29797@shangw.(null)> Reply-To: Gavin Shan References: <20121017215338.GA3577@thinkpad> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="bg08WKrSYDhXBjb5" Content-Disposition: inline In-Reply-To: <20121017215338.GA3577@thinkpad> Sender: owner-linux-mm@kvack.org List-ID: To: Andrea Righi Cc: Andrea Arcangeli , Christoph Lameter , Andrew Morton , linux-mm@kvack.org, linux-kernel@vger.kernel.org --bg08WKrSYDhXBjb5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi Andrea, Do you have chance to have a try on the attached patch? Thanks, Gavin On Wed, Oct 17, 2012 at 11:53:38PM +0200, Andrea Righi wrote: >Just got this on 3.7.0-rc1 (last git commit 1867353): > >[49048.262912] ================================= >[49048.262913] [ INFO: inconsistent lock state ] >[49048.262916] 3.7.0-rc1+ #518 Not tainted >[49048.262918] --------------------------------- >[49048.262919] inconsistent {RECLAIM_FS-ON-W} -> {IN-RECLAIM_FS-W} usage. >[49048.262922] kswapd0/35 [HC0[0]:SC0[0]:HE1:SE1] takes: >[49048.262924] (&mapping->i_mmap_mutex){+.+.?.}, at: [] page_referenced+0x9c/0x2e0 >[49048.262933] {RECLAIM_FS-ON-W} state was registered at: >[49048.262935] [] mark_held_locks+0x86/0x150 >[49048.262938] [] lockdep_trace_alloc+0x67/0xc0 >[49048.262942] [] kmem_cache_alloc_trace+0x33/0x230 >[49048.262945] [] do_mmu_notifier_register+0x87/0x180 >[49048.262948] [] mmu_notifier_register+0x13/0x20 >[49048.262951] [] kvm_dev_ioctl+0x428/0x510 >[49048.262955] [] do_vfs_ioctl+0x98/0x570 >[49048.262959] [] sys_ioctl+0x91/0xb0 >[49048.262962] [] system_call_fastpath+0x16/0x1b >[49048.262966] irq event stamp: 825 >[49048.262968] hardirqs last enabled at (825): [] _raw_spin_unlock_irq+0x30/0x60 >[49048.262971] hardirqs last disabled at (824): [] _raw_spin_lock_irq+0x19/0x80 >[49048.262975] softirqs last enabled at (0): [] copy_process+0x630/0x17c0 >[49048.262979] softirqs last disabled at (0): [< (null)>] (null) >[49048.262981] >[49048.262981] other info that might help us debug this: >[49048.262983] Possible unsafe locking scenario: >[49048.262983] >[49048.262984] CPU0 >[49048.262986] ---- >[49048.262987] lock(&mapping->i_mmap_mutex); >[49048.262989] >[49048.262991] lock(&mapping->i_mmap_mutex); >[49048.262993] >[49048.262993] *** DEADLOCK *** >[49048.262993] >[49048.262995] no locks held by kswapd0/35. >[49048.262996] >[49048.262996] stack backtrace: >[49048.262999] Pid: 35, comm: kswapd0 Not tainted 3.7.0-rc1+ #518 >[49048.263000] Call Trace: >[49048.263005] [] print_usage_bug+0x1f5/0x206 >[49048.263008] [] ? save_stack_trace+0x2f/0x50 >[49048.263011] [] mark_lock+0x295/0x2f0 >[49048.263014] [] ? print_irq_inversion_bug.part.42+0x1f0/0x1f0 >[49048.263017] [] __lock_acquire+0x59d/0x1c20 >[49048.263020] [] ? put_cpu_partial+0x65/0xbd >[49048.263024] [] ? native_sched_clock+0x26/0x90 >[49048.263028] [] ? sched_clock_cpu+0xc5/0x120 >[49048.263031] [] lock_acquire+0x90/0x210 >[49048.263034] [] ? page_referenced+0x9c/0x2e0 >[49048.263038] [] mutex_lock_nested+0x73/0x3d0 >[49048.263041] [] ? page_referenced+0x9c/0x2e0 >[49048.263044] [] ? page_referenced+0x9c/0x2e0 >[49048.263047] [] ? put_lock_stats.isra.26+0xe/0x40 >[49048.263051] [] ? lock_release_holdtime.part.27+0xd4/0x150 >[49048.263055] [] ? __remove_mapping+0xab/0x120 >[49048.263058] [] page_referenced+0x9c/0x2e0 >[49048.263061] [] shrink_page_list+0x3e4/0xa20 >[49048.263064] [] ? native_sched_clock+0x26/0x90 >[49048.263068] [] ? shrink_inactive_list+0x165/0x4b0 >[49048.263071] [] ? _raw_spin_unlock_irq+0x30/0x60 >[49048.263075] [] shrink_inactive_list+0x1f7/0x4b0 >[49048.263079] [] shrink_lruvec+0x44d/0x550 >[49048.263082] [] kswapd+0x703/0xdf0 >[49048.263086] [] ? __init_waitqueue_head+0x60/0x60 >[49048.263090] [] ? shrink_lruvec+0x550/0x550 >[49048.263093] [] kthread+0xed/0x100 >[49048.263097] [] ? flush_kthread_worker+0x190/0x190 >[49048.263100] [] ret_from_fork+0x7c/0xb0 >[49048.263103] [] ? flush_kthread_worker+0x190/0x190 > >Should we use a GFP_NOFS allocation in mmu_notifier_register() or is >there a better way to fix/avoid this? > >Thanks, >-Andrea > >-- >To unsubscribe, send a message with 'unsubscribe linux-mm' in >the body to majordomo@kvack.org. For more info on Linux MM, >see: http://www.linux-mm.org/ . >Don't email: email@kvack.org > --bg08WKrSYDhXBjb5 Content-Type: text/x-diff; charset=us-ascii Content-Disposition: attachment; filename="0001-mm-mmu_notifier-allocate-mmu_notifier-in-advance.patch" --bg08WKrSYDhXBjb5--