Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753809AbYJHE7d (ORCPT ); Wed, 8 Oct 2008 00:59:33 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751018AbYJHE7Z (ORCPT ); Wed, 8 Oct 2008 00:59:25 -0400 Received: from sineb-mail-2.sun.com ([192.18.19.7]:62775 "EHLO sineb-mail-2.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750888AbYJHE7Y (ORCPT ); Wed, 8 Oct 2008 00:59:24 -0400 X-Greylist: delayed 623 seconds by postgrey-1.27 at vger.kernel.org; Wed, 08 Oct 2008 00:59:23 EDT Date: Wed, 08 Oct 2008 10:19:11 +0530 From: Kalpak Shah Subject: Re: ext4 deadlocks In-reply-to: <20081007214637.GA2009@webber.adilger.int> To: Andreas Dilger Cc: Eric Sandeen , Jeremy Fitzhardinge , linux-ext4@vger.kernel.org, Linux Kernel Mailing List Message-id: <1223441351.4007.137.camel@localhost> MIME-version: 1.0 X-Mailer: Evolution 2.8.3 (2.8.3-2.fc6) Content-type: text/plain Content-transfer-encoding: 7BIT References: <48EBB9E9.4030105@goop.org> <48EBC6B9.7000608@sandeen.net> <20081007214637.GA2009@webber.adilger.int> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4243 Lines: 100 On Tue, 2008-10-07 at 15:46 -0600, Andreas Dilger wrote: > On Oct 07, 2008 15:29 -0500, Eric Sandeen wrote: > > Jeremy Fitzhardinge wrote: > > > I tried giving ext4 a spin on my rawhide system, and it appears to > > > deadlock pretty quickly: lots of processed blocked in either ext4 or jbd2. > > > > > > From the look of the sysrq-t dumps I captured, I think beagled is > > > what's triggering it by doing something with EAs. I haven't had any > > > lockups since I killed it off. > > > > > > beagled D 0000000000000000 0 3477 1 > > > ffff880125809778 0000000000000082 0000000000000000 ffff88013b078150 > > > ffffffff8187a780 ffffffff8187a780 ffff88010f8445c0 ffff88013badc5c0 > > > ffff88010f844970 0000000100000001 0000000000000000 ffff88010f844970 > > > Call Trace: > > > [] ? scsi_sg_alloc+0x48/0x4a > > > [] __down_write_nested+0xa3/0xbd > > > [] __down_write+0xb/0xd > > > [] down_write+0x2f/0x33 > > > [] ext4_expand_extra_isize_ea+0x67/0x6f2 [ext4dev] > > > > At first glance it seems that we're trying a down_write on the xattr_sem > > here... > > > > > [] ? jbd2_journal_add_journal_head+0x113/0x1b0 [jbd2] > > > [] ? jbd2_journal_put_journal_head+0x1a/0x56 [jbd2] > > > [] ? jbd2_journal_get_write_access+0x31/0x38 [jbd2] > > > [] ? jbd2_journal_extend+0x1af/0x1ca [jbd2] > > > [] ext4_mark_inode_dirty+0x119/0x18b [ext4dev] > > > [] ext4_dirty_inode+0xab/0xc3 [ext4dev] > > > [] __mark_inode_dirty+0x38/0x194 > > > [] ext4_mb_new_blocks+0x700/0x70f [ext4dev] > > > [] ? mark_page_accessed+0x5f/0x6b > > > [] ? __find_get_block+0x1af/0x1c1 > > > [] ? __wait_on_bit+0x6f/0x7e > > > [] ? sync_buffer+0x0/0x44 > > > [] do_blk_alloc+0x9d/0xb3 [ext4dev] > > > [] ext4_new_meta_blocks+0x34/0x76 [ext4dev] > > > [] ext4_new_meta_block+0x24/0x26 [ext4dev] > > > [] ext4_xattr_block_set+0x50e/0x6d6 [ext4dev] > > > [] ext4_xattr_set_handle+0x281/0x3f0 [ext4dev] > > > > Having already downed it here? > > > > I'll look into it, not 100% sure what path gets us here (between > > in-inode EAs and external block EAs) but I'll see. > > This looks suspiciously like a similar bug fixed in the past by Kalpak, > related to trying to grow large-inode space in ext4_expand_extra_isize_ea(). ext4_xattr_set_handle() eventually ends up calling ext4_mark_inode_dirty() which tries to expand the inode by shifting the EAs. This leads to the xattr_sem being downed again and leading to a deadlock. This patch makes sure that if ext4_xattr_set_handle() is in the call-chain, ext4_mark_inode_dirty() will not expand the inode. Signed-off-by: Kalpak Shah Index: linux-2.6.27-rc7/fs/ext4/xattr.c =================================================================== --- linux-2.6.27-rc7.orig/fs/ext4/xattr.c +++ linux-2.6.27-rc7/fs/ext4/xattr.c @@ -959,6 +959,7 @@ ext4_xattr_set_handle(handle_t *handle, struct ext4_xattr_block_find bs = { .s = { .not_found = -ENODATA, }, }; + unsigned long no_expand; int error; if (!name) @@ -966,6 +967,9 @@ ext4_xattr_set_handle(handle_t *handle, if (strlen(name) > 255) return -ERANGE; down_write(&EXT4_I(inode)->xattr_sem); + no_expand = EXT4_I(inode)->i_state & EXT4_STATE_NO_EXPAND; + EXT4_I(inode)->i_state |= EXT4_STATE_NO_EXPAND; + error = ext4_get_inode_loc(inode, &is.iloc); if (error) goto cleanup; @@ -1042,6 +1046,8 @@ ext4_xattr_set_handle(handle_t *handle, cleanup: brelse(is.iloc.bh); brelse(bs.bh); + if (no_expand == 0) + EXT4_I(inode)->i_state &= ~EXT4_STATE_NO_EXPAND; up_write(&EXT4_I(inode)->xattr_sem); return error; } Thanks, Kalpak -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/