From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754414AbZHTMyx (ORCPT ); Thu, 20 Aug 2009 08:54:53 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754208AbZHTMyw (ORCPT ); Thu, 20 Aug 2009 08:54:52 -0400 Received: from mx2.netapp.com ([216.240.18.37]:35028 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754056AbZHTMyv (ORCPT ); Thu, 20 Aug 2009 08:54:51 -0400 X-IronPort-AV: E=Sophos;i="4.43,414,1246863600"; d="scan'208";a="228087371" Subject: Re: nfs: LOCKDEP warning with 2.6.31-rc6 From: Trond Myklebust To: Peter Zijlstra Cc: Takashi Iwai , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org In-Reply-To: <1250770159.8282.185.camel@twins> References: <1250770159.8282.185.camel@twins> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: NetApp Date: Thu, 20 Aug 2009 08:54:51 -0400 Message-Id: <1250772891.5352.21.camel@heimdal.trondhjem.org> Mime-Version: 1.0 X-Mailer: Evolution 2.26.1 X-OriginalArrivalTime: 20 Aug 2009 12:54:53.0023 (UTC) FILETIME=[6913CEF0:01CA2195] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2009-08-20 at 14:09 +0200, Peter Zijlstra wrote: > 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. I'd be fine with that... Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@netapp.com www.netapp.com