From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755567AbZAHQFs (ORCPT ); Thu, 8 Jan 2009 11:05:48 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752753AbZAHQFj (ORCPT ); Thu, 8 Jan 2009 11:05:39 -0500 Received: from mail.fieldses.org ([141.211.133.115]:55385 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752600AbZAHQFi (ORCPT ); Thu, 8 Jan 2009 11:05:38 -0500 Date: Thu, 8 Jan 2009 11:05:33 -0500 To: Peter Zijlstra Cc: Andrew Morton , linux-nfs@vger.kernel.org, linux-kernel@vger.kernel.org, Neil Brown , Christoph Hellwig Subject: Re: nfsd stuckage Message-ID: <20090108160533.GA15690@fieldses.org> References: <20090106145612.d4d9948d.akpm@linux-foundation.org> <1231426650.11687.459.camel@twins> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1231426650.11687.459.camel@twins> User-Agent: Mutt/1.5.18 (2008-05-17) From: "J. Bruce Fields" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Jan 08, 2009 at 03:57:30PM +0100, Peter Zijlstra wrote: > FWIW lockdep seems to warn about this... > > All I have to do to trigger this is boot the machine and let it sit for > a few minutes. Linus merged a fix (9a8d248e2d2 "nfsd: fix double-locks of directory mutex") last night. If you still see warnings after that, let us know. --b. > > [ 113.552497] ============================================= > [ 113.553289] [ INFO: possible recursive locking detected ] > [ 113.553289] 2.6.28-tip #592 > [ 113.553289] --------------------------------------------- > [ 113.553289] nfsd4/1914 is trying to acquire lock: > [ 113.553289] (&type->i_mutex_dir_key#4){--..}, at: [] vfs_fsync+0x6c/0xb1 > [ 113.553289] > [ 113.553289] but task is already holding lock: > [ 113.553289] (&type->i_mutex_dir_key#4){--..}, at: [] nfsd4_sync_rec_dir+0x22/0x47 [nfsd] > [ 113.553289] > [ 113.553289] other info that might help us debug this: > [ 113.553289] 4 locks held by nfsd4/1914: > [ 113.553289] #0: (nfsd4){--..}, at: [] run_workqueue+0xb6/0x21b > [ 113.553289] #1: ((laundromat_work).work){--..}, at: [] run_workqueue+0xb6/0x21b > [ 113.553289] #2: (client_mutex){--..}, at: [] laundromat_main+0x33/0x24e [nfsd] > [ 113.553289] #3: (&type->i_mutex_dir_key#4){--..}, at: [] nfsd4_sync_rec_dir+0x22/0x47 [nfsd] > [ 113.553289] > [ 113.553289] stack backtrace: > [ 113.553289] Pid: 1914, comm: nfsd4 Not tainted 2.6.28-tip #592 > [ 113.553289] Call Trace: > [ 113.553289] [] __lock_acquire+0xe42/0x161a > [ 113.553289] [] ? __call_rcu+0x7a/0x107 > [ 113.553289] [] lock_acquire+0x55/0x71 > [ 113.553289] [] ? vfs_fsync+0x6c/0xb1 > [ 113.553289] [] mutex_lock_nested+0x4e/0x320 > [ 113.553289] [] ? vfs_fsync+0x6c/0xb1 > [ 113.553289] [] ? __filemap_fdatawrite_range+0x57/0x5f > [ 113.553289] [] vfs_fsync+0x6c/0xb1 > [ 113.553289] [] nfsd_sync_dir+0x15/0x17 [nfsd] > [ 113.553289] [] nfsd4_sync_rec_dir+0x2e/0x47 [nfsd] > [ 113.553289] [] nfsd4_recdir_purge_old+0x45/0x73 [nfsd] > [ 113.553289] [] laundromat_main+0x72/0x24e [nfsd] > [ 113.553289] [] run_workqueue+0x108/0x21b > [ 113.553289] [] ? run_workqueue+0xb6/0x21b > [ 113.553289] [] ? laundromat_main+0x0/0x24e [nfsd] > [ 113.553289] [] worker_thread+0xe5/0xf6 > [ 113.553289] [] ? autoremove_wake_function+0x0/0x3d > [ 113.553289] [] ? worker_thread+0x0/0xf6 > [ 113.553289] [] kthread+0x4e/0x7b > [ 113.553289] [] child_rip+0xa/0x20 > [ 113.553289] [] ? restore_args+0x0/0x30 > [ 113.553289] [] ? kthread+0x0/0x7b > [ 113.553289] [] ? child_rip+0x0/0x20 > >