From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with SMTP id 03B8F6B0023 for ; Thu, 27 Oct 2011 23:43:21 -0400 (EDT) Message-ID: <4EAA2492.3020907@cn.fujitsu.com> Date: Fri, 28 Oct 2011 11:42:10 +0800 From: Wanlong Gao Reply-To: gaowanlong@cn.fujitsu.com MIME-Version: 1.0 Subject: [possible deadlock][3.1.0-g138c4ae] possible circular locking dependency detected Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: linux-fsdevel@vger.kernel.org, "linux-kernel@vger.kernel.org" , linux-mm@kvack.org Hi folks: My dmesg said that: ====================================================== [ INFO: possible circular locking dependency detected ] 3.1.0-138c4ae #2 ------------------------------------------------------- hugemmap05/18198 is trying to acquire lock: (&mm->mmap_sem){++++++}, at: [] might_fault+0x5c/0xb0 but task is already holding lock: (&sb->s_type->i_mutex_key#21){+.+.+.}, at: [] vfs_readdir+0x86/0xe0 which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&sb->s_type->i_mutex_key#21){+.+.+.}: [] validate_chain+0x704/0x860 [] __lock_acquire+0x2fc/0x500 [] lock_acquire+0xb1/0x1a0 [] __mutex_lock_common+0x62/0x420 [] mutex_lock_nested+0x4a/0x60 [] hugetlbfs_file_mmap+0xaa/0x160 [] mmap_region+0x3e1/0x590 [] do_mmap_pgoff+0x364/0x3b0 [] sys_mmap_pgoff+0x209/0x240 [] sys_mmap+0x29/0x30 [] system_call_fastpath+0x16/0x1b -> #0 (&mm->mmap_sem){++++++}: [] check_prev_add+0x537/0x560 [] validate_chain+0x704/0x860 [] __lock_acquire+0x2fc/0x500 [] lock_acquire+0xb1/0x1a0 [] might_fault+0x89/0xb0 [] filldir+0x7e/0xe0 [] dcache_readdir+0x5e/0x230 [] vfs_readdir+0xc0/0xe0 [] sys_getdents+0x89/0x100 [] system_call_fastpath+0x16/0x1b other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&sb->s_type->i_mutex_key); lock(&mm->mmap_sem); lock(&sb->s_type->i_mutex_key); lock(&mm->mmap_sem); *** DEADLOCK *** 1 lock held by hugemmap05/18198: #0: (&sb->s_type->i_mutex_key#21){+.+.+.}, at: [] vfs_readdir+0x86/0xe0 stack backtrace: Pid: 18198, comm: hugemmap05 Not tainted 3.1.0-138c4ae #2 Call Trace: [] print_circular_bug+0x109/0x110 [] check_prev_add+0x537/0x560 [] ? do_anonymous_page+0xf2/0x2d0 [] validate_chain+0x704/0x860 [] __lock_acquire+0x2fc/0x500 [] lock_acquire+0xb1/0x1a0 [] ? might_fault+0x5c/0xb0 [] might_fault+0x89/0xb0 [] ? might_fault+0x5c/0xb0 [] ? __mutex_lock_common+0x2d3/0x420 [] ? vfs_readdir+0x86/0xe0 [] filldir+0x7e/0xe0 [] dcache_readdir+0x5e/0x230 [] ? filldir64+0xf0/0xf0 [] ? filldir64+0xf0/0xf0 [] ? filldir64+0xf0/0xf0 [] vfs_readdir+0xc0/0xe0 [] ? fget+0xee/0x220 [] ? fget_raw+0x220/0x220 [] sys_getdents+0x89/0x100 [] system_call_fastpath+0x16/0x1b Wile hugemmap05 is a test case from LTP. http://ltp.git.sourceforge.net/git/gitweb.cgi?p=ltp/ltp.git;a=blob;f=testcases/kernel/mem/hugetlb/hugemmap/hugemmap05.c;h=50bb8ca23ae9686662740f9ea5d7187affff8b60;hb=HEAD But I don't know how to reproduce this. Thanks -Wanlong Gao -- 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/ . Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ Don't email: email@kvack.org