From: "Aneesh Kumar K.V" Subject: jbd2_handle and i_data_sem circular locking dependency detected Date: Mon, 4 Feb 2008 15:42:28 +0530 Message-ID: <20080204101228.GA1939@skywalker> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Theodore Tso , Andreas Dilger , Mingming Cao , "linux-ext4@vger.kernel.org" To: Jan Kara , Josef Bacik Return-path: Received: from E23SMTP04.au.ibm.com ([202.81.18.173]:49517 "EHLO e23smtp04.au.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750870AbYBDKMj (ORCPT ); Mon, 4 Feb 2008 05:12:39 -0500 Received: from d23relay03.au.ibm.com (d23relay03.au.ibm.com [202.81.18.234]) by e23smtp04.au.ibm.com (8.13.1/8.13.1) with ESMTP id m14ACIF3024975 for ; Mon, 4 Feb 2008 21:12:18 +1100 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.234.96]) by d23relay03.au.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m14ACbGG3449028 for ; Mon, 4 Feb 2008 21:12:37 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m14ACaqO002438 for ; Mon, 4 Feb 2008 21:12:37 +1100 Content-Disposition: inline Sender: linux-ext4-owner@vger.kernel.org List-ID: Hi, This is with the new ext3 -> ext4 migrate code added. The recently added lockdep for jbd2 helped to find this out. We want to hold the i_data_sem on the ext3 inode during migration to prevent walking the ext3 inode when it is being converted to ext4 format. Also we want to avoid file truncation and new blocks being added while converting to ext4. Also we dont want to reserve large number of credits for journal. Any idea how to fix this ? -aneesh ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.24-rc8 #6 ------------------------------------------------------- rm/2401 is trying to acquire lock: (&ei->i_data_sem){----}, at: [] ext4_get_blocks_wrap+0x21/0x108 but task is already holding lock: (jbd2_handle){--..}, at: [] jbd2_journal_start+0xd2/0xff which lock already depends on the new lock. the existing dependency chain (in reverse order) is: -> #1 (jbd2_handle){--..}: [] __lock_acquire+0xa31/0xc1a [] lock_acquire+0x7a/0x94 [] jbd2_journal_start+0xf5/0xff [] ext4_journal_start_sb+0x48/0x4a [] ext4_ext_migrate+0x7d/0x535 [] ext4_ioctl+0x528/0x56c [] do_ioctl+0x50/0x67 [] vfs_ioctl+0x237/0x24a [] sys_ioctl+0x31/0x4b [] sysenter_past_esp+0x5f/0xa5 [] 0xffffffff -> #0 (&ei->i_data_sem){----}: [] __lock_acquire+0x921/0xc1a [] lock_acquire+0x7a/0x94 [] down_read+0x42/0x79 [] ext4_get_blocks_wrap+0x21/0x108 [] ext4_getblk+0x62/0x1c4 [] ext4_find_entry+0x350/0x5b7 [] ext4_unlink+0x6e/0x1a4 [] vfs_unlink+0x49/0x89 [] do_unlinkat+0x96/0x12c [] sys_unlink+0x10/0x12 [] sysenter_past_esp+0x5f/0xa5 [] 0xffffffff other info that might help us debug this: 3 locks held by rm/2401: #0: (&type->i_mutex_dir_key#5/1){--..}, at: [] do_unlinkat+0x5e/0x12c #1: (&sb->s_type->i_mutex_key#8){--..}, at: [] vfs_unlink+0x36/0x89 #2: (jbd2_handle){--..}, at: [] jbd2_journal_start+0xd2/0xff stack backtrace: Pid: 2401, comm: rm Not tainted 2.6.24-rc8 #6 [] show_trace_log_lvl+0x1a/0x2f [] show_trace+0x12/0x14 [] dump_stack+0x6c/0x72 [] print_circular_bug_tail+0x5f/0x68 [] __lock_acquire+0x921/0xc1a [] lock_acquire+0x7a/0x94 [] down_read+0x42/0x79 [] ext4_get_blocks_wrap+0x21/0x108 [] ext4_getblk+0x62/0x1c4 [] ext4_find_entry+0x350/0x5b7 [] ext4_unlink+0x6e/0x1a4 [] vfs_unlink+0x49/0x89 [] do_unlinkat+0x96/0x12c [] sys_unlink+0x10/0x12 [] sysenter_past_esp+0x5f/0xa5