From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755688Ab2CHJP4 (ORCPT ); Thu, 8 Mar 2012 04:15:56 -0500 Received: from e23smtp09.au.ibm.com ([202.81.31.142]:39094 "EHLO e23smtp09.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752159Ab2CHJPt (ORCPT ); Thu, 8 Mar 2012 04:15:49 -0500 From: "Aneesh Kumar K.V" To: linux-mm@kvack.org, akpm@linux-foundation.org, davej@redhat.com, jboyer@redhat.com, tyhicks@canonical.com Cc: linux-kernel@vger.kernel.org, "Aneesh Kumar K.V" Subject: [PATCH] hugetlbfs: lockdep annotate root inode properly Date: Thu, 8 Mar 2012 14:45:16 +0530 Message-Id: <1331198116-13670-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> X-Mailer: git-send-email 1.7.9 x-cbid: 12030800-3568-0000-0000-00000155A585 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: "Aneesh Kumar K.V" This fix the below lockdep warning ====================================================== [ INFO: possible circular locking dependency detected ] 3.3.0-rc4+ #190 Not tainted ------------------------------------------------------- shared/1568 is trying to acquire lock: (&sb->s_type->i_mutex_key#12){+.+.+.}, at: [] hugetlbfs_file_mmap+0x7d/0x108 but task is already holding lock: (&mm->mmap_sem){++++++}, at: [] sys_mmap_pgoff+0xd4/0x12f which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (&mm->mmap_sem){++++++}: [] lock_acquire+0xd5/0xfa [] might_fault+0x6d/0x90 [] filldir+0x6a/0xc2 [] dcache_readdir+0x5c/0x222 [] vfs_readdir+0x76/0xac [] sys_getdents+0x79/0xc9 [] system_call_fastpath+0x16/0x1b -> #0 (&sb->s_type->i_mutex_key#12){+.+.+.}: [] __lock_acquire+0xa6c/0xd60 [] lock_acquire+0xd5/0xfa [] __mutex_lock_common+0x48/0x350 [] mutex_lock_nested+0x2a/0x31 [] hugetlbfs_file_mmap+0x7d/0x108 [] mmap_region+0x26f/0x466 [] do_mmap_pgoff+0x294/0x2ee [] sys_mmap_pgoff+0xf4/0x12f [] sys_mmap+0x1d/0x1f [] system_call_fastpath+0x16/0x1b other info that might help us debug this: Possible unsafe locking scenario: CPU0 CPU1 ---- ---- lock(&mm->mmap_sem); lock(&sb->s_type->i_mutex_key#12); lock(&mm->mmap_sem); lock(&sb->s_type->i_mutex_key#12); *** DEADLOCK *** 1 lock held by shared/1568: #0: (&mm->mmap_sem){++++++}, at: [] sys_mmap_pgoff+0xd4/0x12f stack backtrace: Pid: 1568, comm: shared Not tainted 3.3.0-rc4+ #190 Call Trace: [] print_circular_bug+0x1f8/0x209 [] __lock_acquire+0xa6c/0xd60 [] ? files_lglock_local_lock_cpu+0x61/0x61 [] ? hugetlbfs_file_mmap+0x7d/0x108 [] lock_acquire+0xd5/0xfa [] ? hugetlbfs_file_mmap+0x7d/0x108 Signed-off-by: Aneesh Kumar K.V --- fs/hugetlbfs/inode.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) NOTE: This patch also require http://thread.gmane.org/gmane.linux.file-systems/58795/focus=59565 to remove the lockdep warning diff --git a/fs/hugetlbfs/inode.c b/fs/hugetlbfs/inode.c index 3645cd3..ca4fa70 100644 --- a/fs/hugetlbfs/inode.c +++ b/fs/hugetlbfs/inode.c @@ -459,6 +459,7 @@ static struct inode *hugetlbfs_get_root(struct super_block *sb, inode->i_fop = &simple_dir_operations; /* directory inodes start off with i_nlink == 2 (for "." entry) */ inc_nlink(inode); + lockdep_annotate_inode_mutex_key(inode); } return inode; } -- 1.7.9