From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754075AbZHTMJR (ORCPT ); Thu, 20 Aug 2009 08:09:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753835AbZHTMJQ (ORCPT ); Thu, 20 Aug 2009 08:09:16 -0400 Received: from casper.infradead.org ([85.118.1.10]:59761 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753602AbZHTMJP (ORCPT ); Thu, 20 Aug 2009 08:09:15 -0400 Subject: Re: nfs: LOCKDEP warning with 2.6.31-rc6 From: Peter Zijlstra To: Takashi Iwai Cc: Trond Myklebust , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: References: Content-Type: text/plain Content-Transfer-Encoding: 7bit Date: Thu, 20 Aug 2009 14:09:19 +0200 Message-Id: <1250770159.8282.185.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2009-08-20 at 12:18 +0200, Takashi Iwai wrote: > Hi, > > my machine got a lockdep warning regarding NFS client on 2.6.31-rc6. > Here is the log: > > ======================================================= > [ INFO: possible circular locking dependency detected ] > 2.6.31-rc6-test #12 > ------------------------------------------------------- > soffice.bin/31490 is trying to acquire lock: > (&sb->s_type->i_mutex_key#13){+.+.+.}, at: [] nfs_revalidate_mapping+0x72/0xbe [nfs] > > but task is already holding lock: > (&mm->mmap_sem){++++++}, at: [] sys_mmap2+0x6d/0xb4 > > which lock already depends on the new lock. > > > the existing dependency chain (in reverse order) is: > > -> #1 (&mm->mmap_sem){++++++}: > [] __lock_acquire+0x100e/0x130d > [] lock_acquire+0xb7/0xeb > [] might_fault+0x69/0x9a > [] copy_to_user+0x3c/0x127 > [] filldir64+0xc3/0x108 > [] nfs_do_filldir+0x383/0x4ad [nfs] > [] nfs_readdir+0x7b4/0x830 [nfs] > [] vfs_readdir+0x76/0xb3 > [] sys_getdents64+0x73/0xc3 > [] sysenter_do_call+0x12/0x38 > [] 0xffffffff > > -> #0 (&sb->s_type->i_mutex_key#13){+.+.+.}: > [] __lock_acquire+0xd5e/0x130d > [] lock_acquire+0xb7/0xeb > [] mutex_lock_nested+0x43/0x272 > [] nfs_revalidate_mapping+0x72/0xbe [nfs] > [] nfs_file_mmap+0x5e/0x77 [nfs] > [] mmap_region+0x263/0x40f > [] do_mmap_pgoff+0x264/0x2c7 > [] sys_mmap2+0x81/0xb4 > [] sysenter_do_call+0x12/0x38 > [] 0xffffffff > > other info that might help us debug this: > > 1 lock held by soffice.bin/31490: > #0: (&mm->mmap_sem){++++++}, at: [] sys_mmap2+0x6d/0xb4 > > stack backtrace: > Pid: 31490, comm: soffice.bin Not tainted 2.6.31-rc6-test #12 > Call Trace: > [] ? printk+0x1d/0x33 > [] print_circular_bug_tail+0xaf/0xcb > [] __lock_acquire+0xd5e/0x130d > [] ? nfs_revalidate_mapping+0x72/0xbe [nfs] > [] lock_acquire+0xb7/0xeb > [] ? nfs_revalidate_mapping+0x72/0xbe [nfs] > [] ? nfs_revalidate_mapping+0x72/0xbe [nfs] > [] mutex_lock_nested+0x43/0x272 > [] ? nfs_revalidate_mapping+0x72/0xbe [nfs] > [] ? nfs_have_delegation+0x68/0x82 [nfs] > [] nfs_revalidate_mapping+0x72/0xbe [nfs] > [] nfs_file_mmap+0x5e/0x77 [nfs] > [] mmap_region+0x263/0x40f > [] do_mmap_pgoff+0x264/0x2c7 > [] sys_mmap2+0x81/0xb4 > [] sysenter_do_call+0x12/0x38 > > ======================================================= > > Indeed this looks like a circular lock dependency since copy_*_user() > invokes mm->mmap_sem mutex lock internally. (I hit a similar bug in > the ALSA core ago, thus I know it :) > > The inode lock in vfs_readdir is killable, so it's not critical, > though... Right, I did a number of patches to split up ->mmap() a while ago (ok, a long while ago). http://www.mail-archive.com/linux-arch@vger.kernel.org/msg04493.html Unless someone sees another way out, we should reconsider these, as this warning seems to pop up more frequently.