Skip to contentSkip to conversation

New: umount hangs after fsstress with data=journal

Bug 12624 [email protected] 3 participants 8 messages Feb 3, 2009 – Jun 4, 2009 ext4 file system

lore
Share & tools
lore

[email protected]

author
#0 lore raw

http://bugzilla.kernel.org/show_bug.cgi?id=12624

Summary: umount hangs after fsstress with data=journal
Product: File System
Version: 2.5
KernelVersion: 2.6.29-rc3-git3
Platform: All
OS/Version: Linux
Tree: Mainline
Status: NEW
Severity: normal
Priority: P1
Component: ext4
AssignedTo: [email protected]
ReportedBy: [email protected]

[<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

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
#1 lore raw

[Bug 12624] umount hangs after fsstress with data=journal

http://bugzilla.kernel.org/show_bug.cgi?id=12624

Theodore Tso <[email protected]> changed:

What |Removed |Added
----------------------------------------------------------------------------

                 CC|                            |[email protected]
         Regression|---                         |No

--- Comment #1 from Theodore Tso <[email protected]> 2009-05-19 19:16:31 --- Aneesh, can you reproduce this on a more modern kernel?

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
#2 lore raw

[Bug 12624] umount hangs after fsstress with data=journal

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=12624

--- Comment #2 from Aneesh Kumar K.V <[email protected]> 2009-05-21 12:25:23 --- 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

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
#3 lore raw

[Bug 12624] umount hangs after fsstress with data=journal

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=12624

--- Comment #3 from Aneesh Kumar K.V <[email protected]> 2009-05-22 06:51:43 --- 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 <[email protected]>
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 <[email protected]>
fs/ext4/inode.c +4 -2
index 6e5caa7..ebf7bb3 100644
@@ -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;
Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
maintainer
#4 lore raw

Re: [Bug 12624] umount hangs after fsstress with data=journal

Quoted 9 lines · On Fri, May 22, 2009 at 06:51:43AM +0000, [email protected]…

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 <[email protected]>
Date:   Thu May 21 23:58:17 2009 +0530
Quoted 7 lines

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 <[email protected]>

OK, added to the ext4 patch tree.

- Ted

#5 lore raw

[Bug 12624] umount hangs after fsstress with data=journal

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=12624

--- Comment #4 from Aneesh Kumar K.V <[email protected]> 2009-05-25 18:21:00 --- 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

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
#6 lore raw

[Bug 12624] umount hangs after fsstress with data=journal

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=12624

--- Comment #5 from Theodore Tso <[email protected]> 2009-06-03 21:51:42 ---

Quoted 9 lines · On Fri, May 22, 2009 at 06:51:43AM +0000, [email protected]…

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 <[email protected]>
Date:   Thu May 21 23:58:17 2009 +0530
Quoted 7 lines

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 <[email protected]>

OK, added to the ext4 patch tree.

- Ted

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.
Reviewed-by Josef Bacik Acked-by Jan Kara
#7 lore raw

[Bug 12624] umount hangs after fsstress with data=journal

In reply to [email protected]

http://bugzilla.kernel.org/show_bug.cgi?id=12624

--- Comment #6 from Aneesh Kumar K.V <[email protected]> 2009-06-04 06:32:22 ---

Quoted 21 lines · On Wed, Jun 03, 2009 at 09:51:42PM +0000, [email protected]…

http://bugzilla.kernel.org/show_bug.cgi?id=12624

--- Comment #5 from Theodore Tso <[email protected]> 2009-06-03 21:51:42 ---

Quoted 12 lines · On Fri, May 22, 2009 at 06:51:43AM +0000, [email protected]…

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 <[email protected]>
Date:   Thu May 21 23:58:17 2009 +0530

ext4: Don't look at buffer_heads outside i_size.

Quoted 6 lines
Quoted 4 lines

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 <[email protected]>

OK, added to the ext4 patch tree.

can you add

Reviewed-by Josef Bacik <[email protected]>
Acked-by Jan Kara <[email protected]>

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

Signature · 3 lines
Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching the assignee of the bug.