From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail172.messagelabs.com (mail172.messagelabs.com [216.82.254.3]) by kanga.kvack.org (Postfix) with ESMTP id 7285F6B002F for ; Fri, 28 Oct 2011 02:03:00 -0400 (EDT) Received: by qyk29 with SMTP id 29so1934258qyk.14 for ; Thu, 27 Oct 2011 23:02:58 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <4EAA4263.2090809@cn.fujitsu.com> References: <4EAA2492.3020907@cn.fujitsu.com> <4EAA4263.2090809@cn.fujitsu.com> Date: Fri, 28 Oct 2011 14:02:56 +0800 Message-ID: Subject: Re: [possible deadlock][3.1.0-g138c4ae] possible circular locking dependency detected From: Bob Liu Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: gaowanlong@cn.fujitsu.com Cc: "linux-kernel@vger.kernel.org" , linux-fsdevel@vger.kernel.org, Linux-MM On Fri, Oct 28, 2011 at 1:49 PM, Wanlong Gao wr= ote: > On 10/28/2011 01:44 PM, Bob Liu wrote: > >> On Fri, Oct 28, 2011 at 11:42 AM, Wanlong Gao wrote: >>> Hi folks: >>> >>> My dmesg said that: >>> >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D >>> [ INFO: possible circular locking dependency detected ] >>> 3.1.0-138c4ae #2 >>> ------------------------------------------------------- >>> hugemmap05/18198 is trying to acquire lock: >>> =C2=A0(&mm->mmap_sem){++++++}, at: [] might_fault+0x5= c/0xb0 >>> >>> but task is already holding lock: >>> =C2=A0(&sb->s_type->i_mutex_key#21){+.+.+.}, at: [] v= fs_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){+.+.+.}: >>> =C2=A0 =C2=A0 =C2=A0 [] validate_chain+0x704/0x860 >>> =C2=A0 =C2=A0 =C2=A0 [] __lock_acquire+0x2fc/0x500 >>> =C2=A0 =C2=A0 =C2=A0 [] lock_acquire+0xb1/0x1a0 >>> =C2=A0 =C2=A0 =C2=A0 [] __mutex_lock_common+0x62/0x42= 0 >>> =C2=A0 =C2=A0 =C2=A0 [] mutex_lock_nested+0x4a/0x60 >>> =C2=A0 =C2=A0 =C2=A0 [] hugetlbfs_file_mmap+0xaa/0x16= 0 >>> =C2=A0 =C2=A0 =C2=A0 [] mmap_region+0x3e1/0x590 >>> =C2=A0 =C2=A0 =C2=A0 [] do_mmap_pgoff+0x364/0x3b0 >>> =C2=A0 =C2=A0 =C2=A0 [] sys_mmap_pgoff+0x209/0x240 >>> =C2=A0 =C2=A0 =C2=A0 [] sys_mmap+0x29/0x30 >>> =C2=A0 =C2=A0 =C2=A0 [] system_call_fastpath+0x16/0x1= b >>> >>> -> #0 (&mm->mmap_sem){++++++}: >>> =C2=A0 =C2=A0 =C2=A0 [] check_prev_add+0x537/0x560 >>> =C2=A0 =C2=A0 =C2=A0 [] validate_chain+0x704/0x860 >>> =C2=A0 =C2=A0 =C2=A0 [] __lock_acquire+0x2fc/0x500 >>> =C2=A0 =C2=A0 =C2=A0 [] lock_acquire+0xb1/0x1a0 >>> =C2=A0 =C2=A0 =C2=A0 [] might_fault+0x89/0xb0 >>> =C2=A0 =C2=A0 =C2=A0 [] filldir+0x7e/0xe0 >>> =C2=A0 =C2=A0 =C2=A0 [] dcache_readdir+0x5e/0x230 >>> =C2=A0 =C2=A0 =C2=A0 [] vfs_readdir+0xc0/0xe0 >>> =C2=A0 =C2=A0 =C2=A0 [] sys_getdents+0x89/0x100 >>> =C2=A0 =C2=A0 =C2=A0 [] system_call_fastpath+0x16/0x1= b >>> >>> other info that might help us debug this: >>> >>> =C2=A0Possible unsafe locking scenario: >>> >>> =C2=A0 =C2=A0 =C2=A0 CPU0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0CPU1 >>> =C2=A0 =C2=A0 =C2=A0 ---- =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0---- >>> =C2=A0lock(&sb->s_type->i_mutex_key); >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lock(&mm->mmap_sem); >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 lock(&sb->s_type->i_mutex_key); >>> =C2=A0lock(&mm->mmap_sem); >>> >>> =C2=A0*** DEADLOCK *** >>> >>> 1 lock held by hugemmap05/18198: >>> =C2=A0#0: =C2=A0(&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: >>> =C2=A0[] print_circular_bug+0x109/0x110 >>> =C2=A0[] check_prev_add+0x537/0x560 >>> =C2=A0[] ? do_anonymous_page+0xf2/0x2d0 >>> =C2=A0[] validate_chain+0x704/0x860 >>> =C2=A0[] __lock_acquire+0x2fc/0x500 >>> =C2=A0[] lock_acquire+0xb1/0x1a0 >>> =C2=A0[] ? might_fault+0x5c/0xb0 >>> =C2=A0[] might_fault+0x89/0xb0 >>> =C2=A0[] ? might_fault+0x5c/0xb0 >>> =C2=A0[] ? __mutex_lock_common+0x2d3/0x420 >>> =C2=A0[] ? vfs_readdir+0x86/0xe0 >>> =C2=A0[] filldir+0x7e/0xe0 >>> =C2=A0[] dcache_readdir+0x5e/0x230 >>> =C2=A0[] ? filldir64+0xf0/0xf0 >>> =C2=A0[] ? filldir64+0xf0/0xf0 >>> =C2=A0[] ? filldir64+0xf0/0xf0 >>> =C2=A0[] vfs_readdir+0xc0/0xe0 >>> =C2=A0[] ? fget+0xee/0x220 >>> =C2=A0[] ? fget_raw+0x220/0x220 >>> =C2=A0[] sys_getdents+0x89/0x100 >>> =C2=A0[] system_call_fastpath+0x16/0x1b >>> >> >> Please try this patch "lockdep: Add helper function for dir vs file >> i_mutex annotation" by josh. >> http://git.kernel.org/?p=3Dlinux/kernel/git/next/linux-next.git;a=3Dcomm= itdiff;h=3De096d0c7e2e4e5893792db865dd065ac73cf1f00 >> > > > Oh, it looks like can fix this bug, but I also can't reproduce it whether= with or without this patch. > Make sure CONFIG_DEBUG_LOCK_ALLOC was set. --=20 Regards, --Bob -- 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