Bug 12624 - umount hangs after fsstress with data=journal
Summary: umount hangs after fsstress with data=journal
Status: RESOLVED CODE_FIX
Alias: None
Product: File System
Classification: Unclassified
Component: ext4 (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Jan Kara
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-02-03 09:32 UTC by Aneesh Kumar K.V
Modified: 2011-01-12 19:08 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.29-rc3-git3
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description Aneesh Kumar K.V 2009-02-03 09:32:45 UTC
[<c0498f7f>] inode_wait+0x8/0xc
[<c0499381>] clear_inode+0x4e/0xb9
[<c04997e1>] dispose_list+0x3c/0xc1
[<c0499adf>] invalidate_inodes+0xb3/0xc8
[<c048b9cc>] generic_shutdown_super+0x3c/0xc4
[<c048ba71>] kill_block_super+0x1d/0x31
[<c048bb2d>] deactivate_super+0x57/0x6a
[<c049c375>] mntput_no_expire+0xc2/0xf5
[<c049c84f>] sys_umount+0x284/0x2cf
[<c0403201>] sysenter_do_call+0x12/0x31
[<ffffffff>] 0xffffffff
Comment 1 Theodore Tso 2009-05-19 19:16:31 UTC
Aneesh, can you reproduce this on a more modern kernel?
Comment 2 Aneesh Kumar K.V 2009-05-21 12:25:23 UTC
Testing with the latest patch queue hit the BUG_ON 
noalloc_get_block_write. I guess for data=journal
noalloc_get_block_write can get called with create = 1;
------------[ cut here ]------------
kernel BUG at fs/ext4/inode.c:2454!
invalid opcode: 0000 [#1] PREEMPT SMP
last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:01:01.0/class
Modules linked in: autofs4 hidp sbs sbshc battery ac parport_pc lp parport i2c_i801 i2c_core e752x_edac edac_core i6300esb tg3 libphy qla2xxx scsi_transport_fc dm_multipath dm_mirror dm_region_hash dm_log dm_mod loop xt_tcpudp ip6t_REJECT ipv6 ipt_REJECT x_tables sunrpc rfcomm bnep l2cap bluetooth bridge stp sg rtc_cmos rtc_core rtc_lib pcspkr button ata_piix libata mptspi mptscsih mptbase scsi_transport_spi sd_mod scsi_mod ext3 jbd uhci_hcd ohci_hcd ehci_hcd [last unloaded: ip_tables]

Pid: 2641, comm: pdflush Not tainted (2.6.30-rc6-autotest #1) IBM BladeCenter HS20 -[88432RG]-
EIP: 0060:[<c04e195b>] EFLAGS: 00010246 CPU: 3
EIP is at noalloc_get_block_write+0x44/0x61
EAX: 00000000 EBX: f71069d0 ECX: f63b2720 EDX: 00000001
ESI: 00000011 EDI: 00000000 EBP: e0cc4d90 ESP: e0cc4d84
 DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process pdflush (pid: 2641, ti=e0cc4000 task=f63b2230 task.ti=e0cc4000)
Stack:
 00000000 c56da980 e0cc4f70 e0cc4df4 c04ac354 f7086dd8 00000001 f6d32d00
 00000000 c56da980 f71069d0 00000800 00000011 00000000 00000400 f7086390
 e0cc4ddc fffffc00 fffffc00 00000400 f63b2230 00000800 f63b26f8 e0cc4e00
Call Trace:
 [<c04ac354>] ? __block_prepare_write+0x13b/0x311
 [<c04ac542>] ? block_prepare_write+0x18/0x27
 [<c04e1917>] ? noalloc_get_block_write+0x0/0x61
 [<c04e3f9e>] ? ext4_journalled_writepage+0xd8/0x1fa
 [<c04e1917>] ? noalloc_get_block_write+0x0/0x61
 [<c04714b4>] ? __writepage+0xb/0x23
 [<c04718b6>] ? write_cache_pages+0x1c0/0x2b3
 [<c04714a9>] ? __writepage+0x0/0x23
 [<c04719c6>] ? generic_writepages+0x1d/0x27
 [<c04719fc>] ? do_writepages+0x2c/0x34
 [<c04a7602>] ? __writeback_single_inode+0x145/0x275
 [<c04a7a74>] ? generic_sync_sb_inodes+0x1a9/0x2de
 [<c04a7bb1>] ? sync_sb_inodes+0x8/0xa
 [<c04a7d24>] ? writeback_inodes+0x52/0x95
 [<c04725c7>] ? wb_kupdate+0x8b/0xed
 [<c0472985>] ? pdflush+0x0/0x1d5
 [<c0472a7d>] ? pdflush+0xf8/0x1d5
 [<c047253c>] ? wb_kupdate+0x0/0xed
 [<c043bba6>] ? kthread+0x45/0x6b
 [<c043bb61>] ? kthread+0x0/0x6b
 [<c040345b>] ? kernel_thread_helper+0x7/0x10
Code: 00 00 3b 50 0c 74 04 0f 0b eb fe 6a 00 31 c0 ff 75 08 d3 ea 52 89 da 57 56 e8 f1 fc ff ff 83 c4 14 83 7d 0c 00 74 08 85 c0 75 04 <0f> 0b eb fe 85 c0 7e 0d 8b 4b 64 8b 55 08 d3 e0 89 42 14 31 c0
EIP: [<c04e195b>] noalloc_get_block_write+0x44/0x61 SS:ESP 0068:e0cc4d84
---[ end trace 994dd47b9422fac1 ]---


-aneesh
Comment 3 Aneesh Kumar K.V 2009-05-22 06:51:43 UTC
I guess we would need this patch. But i am still hitting the BUG_ON.
Will try to debug further later today.

-aneesh

commit 85ddb1581222bac63035c16a6536b0a5a2cd60a0
Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
Date:   Thu May 21 23:58:17 2009 +0530

    ext4: Don't look at buffer_heads outside i_size.
    
    
    Buffer heads outside i_size will be unmapped. So when we
    are doing "walk_page_buffers" limit ourself to i_size.
    
    Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index 6e5caa7..ebf7bb3 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -2514,7 +2514,7 @@ static int ext4_da_writepage(struct page *page,
 		 * all are mapped and non delay. We don't want to
 		 * do block allocation here.
 		 */
-		ret = block_prepare_write(page, 0, PAGE_CACHE_SIZE,
+		ret = block_prepare_write(page, 0, len,
 					  noalloc_get_block_write);
 		if (!ret) {
 			page_bufs = page_buffers(page);
@@ -2536,7 +2536,7 @@ static int ext4_da_writepage(struct page *page,
 			return 0;
 		}
 		/* now mark the buffer_heads as dirty and uptodate */
-		block_commit_write(page, 0, PAGE_CACHE_SIZE);
+		block_commit_write(page, 0, len);
 	}
 
 	if (test_opt(inode->i_sb, NOBH) && ext4_should_writeback_data(inode))
@@ -3210,6 +3210,8 @@ static int ext4_normal_writepage(struct page *page,
 static int __ext4_journalled_writepage(struct page *page,
 				struct writeback_control *wbc)
 {
+	loff_t size;
+	unsigned int len;
 	struct address_space *mapping = page->mapping;
 	struct inode *inode = mapping->host;
 	struct buffer_head *page_bufs;
@@ -3217,14 +3219,19 @@ static int __ext4_journalled_writepage(struct page *page,
 	int ret = 0;
 	int err;
 
-	ret = block_prepare_write(page, 0, PAGE_CACHE_SIZE,
+	size = i_size_read(inode);
+	if (page->index == size >> PAGE_CACHE_SHIFT)
+		len = size & ~PAGE_CACHE_MASK;
+	else
+		len = PAGE_CACHE_SIZE;
+
+	ret = block_prepare_write(page, 0, len,
 				  noalloc_get_block_write);
 	if (ret != 0)
 		goto out_unlock;
 
 	page_bufs = page_buffers(page);
-	walk_page_buffers(handle, page_bufs, 0, PAGE_CACHE_SIZE, NULL,
-								bget_one);
+	walk_page_buffers(handle, page_bufs, 0, len, NULL, bget_one);
 	/* As soon as we unlock the page, it can go away, but we have
 	 * references to buffers so we are safe */
 	unlock_page(page);
@@ -3235,19 +3242,19 @@ static int __ext4_journalled_writepage(struct page *page,
 		goto out;
 	}
 
-	ret = walk_page_buffers(handle, page_bufs, 0,
-			PAGE_CACHE_SIZE, NULL, do_journal_get_write_access);
+	ret = walk_page_buffers(handle, page_bufs, 0, len,
+				NULL, do_journal_get_write_access);
 
-	err = walk_page_buffers(handle, page_bufs, 0,
-				PAGE_CACHE_SIZE, NULL, write_end_fn);
+	err = walk_page_buffers(handle, page_bufs, 0, len,
+				NULL, write_end_fn);
 	if (ret == 0)
 		ret = err;
 	err = ext4_journal_stop(handle);
 	if (!ret)
 		ret = err;
 
-	walk_page_buffers(handle, page_bufs, 0,
-				PAGE_CACHE_SIZE, NULL, bput_one);
+	walk_page_buffers(handle, page_bufs, 0, len,
+				NULL, bput_one);
 	EXT4_I(inode)->i_state |= EXT4_STATE_JDATA;
 	goto out;
Comment 4 Aneesh Kumar K.V 2009-05-25 18:21:00 UTC
Filesystem with 4K blocksize works fine.
Filesystem with 1k blocksize fails when fsx-linux is run with mmap write
anebled.
Filesystem with 1k blocksize works fine when we disable mmap write in
fsx-linux with -W option.

-aneesh
Comment 5 Theodore Tso 2009-06-03 21:51:42 UTC
On Fri, May 22, 2009 at 06:51:43AM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> I guess we would need this patch. But i am still hitting the BUG_ON.
> Will try to debug further later today.
> 
> -aneesh
> 
> commit 85ddb1581222bac63035c16a6536b0a5a2cd60a0
> Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> Date:   Thu May 21 23:58:17 2009 +0530
> 
>     ext4: Don't look at buffer_heads outside i_size.
> 
> 
>     Buffer heads outside i_size will be unmapped. So when we
>     are doing "walk_page_buffers" limit ourself to i_size.
> 
>     Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>

OK, added to the ext4 patch tree.

						- Ted
Comment 6 Aneesh Kumar K.V 2009-06-04 06:32:22 UTC
On Wed, Jun 03, 2009 at 09:51:42PM +0000, bugzilla-daemon@bugzilla.kernel.org wrote:
> http://bugzilla.kernel.org/show_bug.cgi?id=12624
> 
> 
> 
> 
> 
> --- Comment #5 from Theodore Tso <tytso@mit.edu>  2009-06-03 21:51:42 ---
> On Fri, May 22, 2009 at 06:51:43AM +0000, bugzilla-daemon@bugzilla.kernel.org
> wrote:
> > I guess we would need this patch. But i am still hitting the BUG_ON.
> > Will try to debug further later today.
> > 
> > -aneesh
> > 
> > commit 85ddb1581222bac63035c16a6536b0a5a2cd60a0
> > Author: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> > Date:   Thu May 21 23:58:17 2009 +0530
> > 
> >     ext4: Don't look at buffer_heads outside i_size.
> > 
> > 
> >     Buffer heads outside i_size will be unmapped. So when we
> >     are doing "walk_page_buffers" limit ourself to i_size.
> > 
> >     Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
> 
> OK, added to the ext4 patch tree.


can you add

Reviewed-by: Josef Bacik <jbacik@redhat.com>
Acked-by: Jan Kara <jack@suse.cz> 

As can be found here

http://article.gmane.org/gmane.comp.file-systems.ext4/13470
http://article.gmane.org/gmane.comp.file-systems.ext4/13479

-aneesh
Comment 7 Eric Sandeen 2010-03-25 22:21:53 UTC
Aneesh, this worked for me on upstream:

# mount -o data=journal /dev/sdb5 /mnt/test
# ltp/fsstress -d /mnt/test -n 10000 -p 4
# umount /mnt/test

Any idea if this is still a problem?
Comment 8 Aneesh Kumar K.V 2010-03-26 10:00:37 UTC
On Thu, 25 Mar 2010 22:21:56 GMT, bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=12624
> 
> 
> Eric Sandeen <sandeen@redhat.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |sandeen@redhat.com
> 
> 
> 
> 
> --- Comment #7 from Eric Sandeen <sandeen@redhat.com>  2010-03-25 22:21:53
> ---
> Aneesh, this worked for me on upstream:
> 
> # mount -o data=journal /dev/sdb5 /mnt/test
> # ltp/fsstress -d /mnt/test -n 10000 -p 4
> # umount /mnt/test
> 
> Any idea if this is still a problem?
> 

I haven't seen the problem after that. I also didn't debug the initial
problem to understand whey the umount was really hanging . So may be we
can close the bug and later open this if we hit the issue.

-aneesh
Comment 9 Jan Kara 2011-01-12 19:08:03 UTC
Closing the bug as it seems to be fixed (per comment #8).

Note You need to log in before you can comment on or make changes to this bug.