From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030357AbWFJIAn (ORCPT ); Sat, 10 Jun 2006 04:00:43 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030358AbWFJIAn (ORCPT ); Sat, 10 Jun 2006 04:00:43 -0400 Received: from mx2.mail.elte.hu ([157.181.151.9]:31426 "EHLO mx2.mail.elte.hu") by vger.kernel.org with ESMTP id S1030357AbWFJIAm (ORCPT ); Sat, 10 Jun 2006 04:00:42 -0400 Date: Sat, 10 Jun 2006 09:59:54 +0200 From: Ingo Molnar To: Anton Altaparmakov Cc: Miles Lane , LKML , Andrew Morton , Arjan van de Ven Subject: Re: 2.6.17-rc6-mm1 -- BUG: possible circular locking deadlock detected! Message-ID: <20060610075954.GA30119@elte.hu> References: <1149751953.10056.10.camel@imp.csi.cam.ac.uk> <20060608095522.GA30946@elte.hu> <1149764032.10056.82.camel@imp.csi.cam.ac.uk> <20060608112306.GA4234@elte.hu> <1149840563.3619.46.camel@imp.csi.cam.ac.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1149840563.3619.46.camel@imp.csi.cam.ac.uk> User-Agent: Mutt/1.4.2.1i X-ELTE-SpamScore: -3.1 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 2.0 X-ELTE-SpamCheck-Details: score=-3.1 required=5.9 tests=ALL_TRUSTED,AWL,BAYES_50 autolearn=no SpamAssassin version=3.0.3 -3.3 ALL_TRUSTED Did not pass through any untrusted hosts 0.0 BAYES_50 BODY: Bayesian spam probability is 40 to 60% [score: 0.5000] 0.2 AWL AWL: From: address is in the auto white-list X-ELTE-VirusStatus: clean Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org * Anton Altaparmakov wrote: > The normal access pattern (B) where the runlist lock is always taken > first. And the mft record lock is taken second and only if the > runlist is incomplete in-memory. > > Of course on file modification, this is also the case, the runlist > lock is taken first, then the mft record lock is taken and thus both > the runlist and the inode can be updated with the new data (e.g. on a > file extend). thanks for the detailed explanation! I have annotated the code for the lock validator as much as i could, by: - excluding ntfs_fill_super() from the locking rules, - 'splitting' the MFT's mrec_lock and runlist->lock locking rules from the other inodes's locking rules, - splitting the mrec_lock rules of extent inodes. (We map them recursively while having the main inode mft record mapped. The nesting is safe because inode->extent_inode is a noncircular relation.) Still there seems to be a case that the validator does not grok: load_attribute_list() seems to take the lock in the opposite order from what you described above. What locking detail am i missing? [let me know if you need all dependency events leading up to this message from the validator] Ingo ======================================================= [ INFO: possible circular locking dependency detected ] ------------------------------------------------------- ls/2581 is trying to acquire lock: (&rl->lock){----}, at: [] load_attribute_list+0xfb/0x3c0 but task is already holding lock: (&ni->mrec_lock){--..}, at: [] map_mft_record_type+0x55/0x2d0 which lock already depends on the new lock, which could lead to circular locking dependencies. the existing dependency chain (in reverse order) is: -> #1 (&ni->mrec_lock){--..}: [] lock_acquire+0x6f/0x90 [] mutex_lock_nested+0x73/0x2a0 [] map_mft_record+0x53/0x2c0 [] ntfs_map_runlist_nolock+0x3d8/0x530 [] ntfs_map_runlist+0x41/0x70 [] ntfs_readpage+0x8c9/0x9b0 [] read_cache_page+0xac/0x150 [] ntfs_statfs+0x41d/0x660 [] vfs_statfs+0x54/0x70 [] vfs_statfs64+0x18/0x30 [] sys_statfs64+0x64/0xa0 [] sysenter_past_esp+0x56/0x8d -> #0 (&rl->lock){----}: [] lock_acquire+0x6f/0x90 [] down_read_nested+0x2a/0x40 [] load_attribute_list+0xfb/0x3c0 [] ntfs_read_locked_inode+0xcee/0x15d0 [] ntfs_iget+0x55/0x80 [] ntfs_lookup+0x14a/0x740 [] do_lookup+0x126/0x150 [] __link_path_walk+0x813/0xe50 [] link_path_walk+0x4c/0xf0 [] do_path_lookup+0xad/0x260 [] __user_walk_fd+0x38/0x60 [] vfs_lstat_fd+0x1e/0x50 [] vfs_lstat+0x11/0x20 [] sys_lstat64+0x14/0x30 [] sysenter_past_esp+0x56/0x8d other info that might help us debug this: 2 locks held by ls/2581: #0: (&inode->i_mutex){--..}, at: [] mutex_lock+0x8/0x10 #1: (&ni->mrec_lock){--..}, at: [] map_mft_record_type+0x55/0x2d0 stack backtrace: [] show_trace+0x12/0x20 [] dump_stack+0x19/0x20 [] print_circular_bug_tail+0x61/0x70 [] __lock_acquire+0x74f/0xde0 [] lock_acquire+0x6f/0x90 [] down_read_nested+0x2a/0x40 [] load_attribute_list+0xfb/0x3c0 [] ntfs_read_locked_inode+0xcee/0x15d0 [] ntfs_iget+0x55/0x80 [] ntfs_lookup+0x14a/0x740 [] do_lookup+0x126/0x150 [] __link_path_walk+0x813/0xe50 [] link_path_walk+0x4c/0xf0 [] do_path_lookup+0xad/0x260 [] __user_walk_fd+0x38/0x60 [] vfs_lstat_fd+0x1e/0x50 [] vfs_lstat+0x11/0x20 [] sys_lstat64+0x14/0x30 [] sysenter_past_esp+0x56/0x8d