From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754811Ab1J1Fuc (ORCPT ); Fri, 28 Oct 2011 01:50:32 -0400 Received: from cn.fujitsu.com ([222.73.24.84]:60960 "EHLO song.cn.fujitsu.com" rhost-flags-OK-FAIL-OK-OK) by vger.kernel.org with ESMTP id S1753028Ab1J1Fub (ORCPT ); Fri, 28 Oct 2011 01:50:31 -0400 Message-ID: <4EAA4263.2090809@cn.fujitsu.com> Date: Fri, 28 Oct 2011 13:49:23 +0800 From: Wanlong Gao Reply-To: gaowanlong@cn.fujitsu.com Organization: FNST User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.15) Gecko/20110322 Red Hat/3.1.9-3.el6_0 Thunderbird/3.1.9 MIME-Version: 1.0 To: Bob Liu CC: "linux-kernel@vger.kernel.org" Subject: Re: [possible deadlock][3.1.0-g138c4ae] possible circular locking dependency detected References: <4EAA2492.3020907@cn.fujitsu.com> In-Reply-To: X-MIMETrack: Itemize by SMTP Server on mailserver/fnst(Release 8.5.1FP4|July 25, 2010) at 2011-10-28 13:48:28, Serialize by Router on mailserver/fnst(Release 8.5.1FP4|July 25, 2010) at 2011-10-28 13:48:33, Serialize complete at 2011-10-28 13:48:33 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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: >> >> ====================================================== >> [ 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 >> > > Please try this patch "lockdep: Add helper function for dir vs file > i_mutex annotation" by josh. > http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=commitdiff;h=e096d0c7e2e4e5893792db865dd065ac73cf1f00 > Oh, it looks like can fix this bug, but I also can't reproduce it whether with or without this patch. Thanks -Wanlong Gao