From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753067Ab2CHVDC (ORCPT ); Thu, 8 Mar 2012 16:03:02 -0500 Received: from mail.linuxfoundation.org ([140.211.169.12]:60828 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752908Ab2CHVC6 (ORCPT ); Thu, 8 Mar 2012 16:02:58 -0500 Date: Thu, 8 Mar 2012 13:02:56 -0800 From: Andrew Morton To: "Aneesh Kumar K.V" Cc: linux-mm@kvack.org, davej@redhat.com, jboyer@redhat.com, tyhicks@canonical.com, linux-kernel@vger.kernel.org, Al Viro , Peter Zijlstra , Mimi Zohar Subject: Re: [PATCH] hugetlbfs: lockdep annotate root inode properly Message-Id: <20120308130256.c7855cbd.akpm@linux-foundation.org> In-Reply-To: <1331198116-13670-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> References: <1331198116-13670-1-git-send-email-aneesh.kumar@linux.vnet.ibm.com> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 8 Mar 2012 14:45:16 +0530 "Aneesh Kumar K.V" wrote: > From: "Aneesh Kumar K.V" > > This fix the below lockdep warning OK, what's going on here. > ====================================================== > [ 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 > Why have these lockdep warnings started coming out now - was the VFS changed to newly take i_mutex somewhere in the directory handling? Sigh. Was lockdep_annotate_inode_mutex_key() sufficiently self-explanatory to justify leaving it undocumented? OK, the patch looks correct given the explanation in e096d0c7e2e, but I'd like to understand why it becomes necessary only now. > NOTE: This patch also require > http://thread.gmane.org/gmane.linux.file-systems/58795/focus=59565 > to remove the lockdep warning And that patch has been basically ignored. Sigh. I guess I'll grab both patches, but I'm not confident in doing so without an overall explanation of what is happening here.