From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751812AbWG0Gvc (ORCPT ); Thu, 27 Jul 2006 02:51:32 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751839AbWG0Gvb (ORCPT ); Thu, 27 Jul 2006 02:51:31 -0400 Received: from smtp102.mail.mud.yahoo.com ([209.191.85.212]:39612 "HELO smtp102.mail.mud.yahoo.com") by vger.kernel.org with SMTP id S1751812AbWG0Gvb (ORCPT ); Thu, 27 Jul 2006 02:51:31 -0400 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.au; h=Received:Message-ID:Date:From:User-Agent:X-Accept-Language:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=e11c0/wKtplmpT+2I+go9x4ny6GGXVVVsZN/IWXCANchBbBc1SlY0A6zO+ENzb1c5L3lM+GVurcYAZxtP7BrtLOE2fnXiLpD8gTtn8WHNw8I94459N+h5ClYa3SZldE5JsFZVyaxyq40/F/aVfh1OhS+wYSkEryOp+GOVUHpLkE= ; Message-ID: <44C86271.9030603@yahoo.com.au> Date: Thu, 27 Jul 2006 16:51:29 +1000 From: Nick Piggin User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20051007 Debian/1.7.12-1 X-Accept-Language: en MIME-Version: 1.0 To: Andrew Morton CC: Rolf Eike Beer , linux-kernel@vger.kernel.org, Anton Altaparmakov Subject: Re: [BUG?] possible recursive locking detected References: <200607261805.26711.eike-kernel@sf-tec.de> <20060726225311.f51cee6d.akpm@osdl.org> In-Reply-To: <20060726225311.f51cee6d.akpm@osdl.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Andrew Morton wrote: > On Wed, 26 Jul 2006 18:05:21 +0200 > Rolf Eike Beer wrote: > > >>Hi, >> >>I did some memory stress test (allocating and mlock()ing a huge number of >>pages) from userspace. At the very beginning of that I got that error long >>before the system got unresponsible and the oom killer dropped in. >> >>Eike >> >>============================================= >>[ INFO: possible recursive locking detected ] >>kded/5304 is trying to acquire lock: >> (&inode->i_mutex){--..}, at: [] mutex_lock+0x21/0x24 >> >>but task is already holding lock: >> (&inode->i_mutex){--..}, at: [] mutex_lock+0x21/0x24 >> >>other info that might help us debug this: >>3 locks held by kded/5304: >> #0: (&inode->i_mutex){--..}, at: [] mutex_lock+0x21/0x24 >> #1: (shrinker_rwsem){----}, at: [] shrink_slab+0x25/0x136 >> #2: (&type->s_umount_key#14){----}, at: [] prune_dcache+0xf6/0x144 >> >>stack backtrace: >> [] show_trace_log_lvl+0x54/0xfd >> [] show_trace+0xd/0x10 >> [] dump_stack+0x17/0x1c >> [] __lock_acquire+0x753/0x99c >> [] lock_acquire+0x4a/0x6a >> [] __mutex_lock_slowpath+0xb0/0x1f4 >> [] mutex_lock+0x21/0x24 >> [] ntfs_put_inode+0x3b/0x74 [ntfs] >> [] iput+0x33/0x6a >> [] dentry_iput+0x5b/0x73 >> [] prune_one_dentry+0x56/0x79 >> [] prune_dcache+0x10a/0x144 >> [] shrink_dcache_memory+0x19/0x31 >> [] shrink_slab+0xd0/0x136 >> [] try_to_free_pages+0x129/0x1d5 >> [] __alloc_pages+0x18e/0x284 >> [] read_cache_page+0x59/0x131 >> [] ext2_get_page+0x1c/0x1ff >> [] ext2_find_entry+0x72/0x139 >> [] ext2_inode_by_name+0xe/0x2e >> [] ext2_lookup+0x1f/0x65 >> [] do_lookup+0xa0/0x134 >> [] __link_path_walk+0x7a5/0xbe4 >> [] link_path_walk+0x50/0xca >> [] do_path_lookup+0x212/0x25a >> [] __user_walk_fd+0x2d/0x41 >> [] vfs_stat_fd+0x19/0x40 >> [] vfs_stat+0x11/0x13 >> [] sys_stat64+0x14/0x2a >> [] sysenter_past_esp+0x56/0x8d > > > We hold the ext2 directory mutex, and ntfs_put_inode is trying to take an > ntfs i_mutex. Not a deadlock as such, but it could become one in ntfs if > ntfs ever does a __GFP_WAIT allocation inside i_mutex, which it surely > does. Though it should be using GFP_NOFS, right? So the dcache shrinker would not reenter the fs in that case. I'm surprised ext2 is allocating with __GFP_FS set, though. Would that cause any problem? -- SUSE Labs, Novell Inc. Send instant messages to your online friends http://au.messenger.yahoo.com