Ext3 users - Dec 2002 - Assertion failure in do_get_write_access() at fs/jbd/transaction.c:746

I guess this could be filed under the 'shot myself in the foot' section,
but I figured I'd report it anyways..

Kernel 2.5.50-bk6, x86, preempt, PIIX IDE, ext3 fs.

I dd'ed the first part of a ext3 partition to tmp, then mounted it via
loopback. (the image passed a fsck, except for warning about corrupt part.
table or superblock)  I tried to 'cd' into a directory within that
mount,
and got this:


EXT3 FS 2.4-0.9.16, 02 Dec 2001 on loop(7,0), internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Assertion failure in do_get_write_access() at fs/jbd/transaction.c:746:
"handle-
>h_buffer_credits > 0"
------------[ cut here ]------------
kernel BUG at fs/jbd/transaction.c:746!
invalid operand: 0000
CPU:    0
EIP:    0060:[<c01722f7>]    Not tainted
EFLAGS: 00010202
EIP is at do_get_write_access+0x3f3/0x530
eax: 0000006a   ebx: c909c000   ecx: c13bcc80   edx: c02f1570
esi: c952c400   edi: c7290a84   ebp: c909dd20   esp: c909dcf0
ds: 0068   es: 0068   ss: 0068
Process bash (pid: 227, threadinfo=c909c000 task=c13bcc80)
Stack: c0291680 c0291ace c0291660 000002ea c0291be6 c952c494 c8d57b04 c3543e2c
       00000000 00000000 00000000 c9237dc4 c909dd44 c0172487 c8d57b04 c3543e2c
       00000000 00000000 c952c200 c9a27a98 c952c400 c909dd80 c01695df c8d57b04
Call Trace:
 [<c0172487>] journal_get_write_access+0x53/0x78
 [<c01695df>] ext3_do_update_inode+0x21f/0x3e0
 [<c0169b15>] ext3_reserve_inode_write+0x31/0xb0
 [<c0169ab5>] ext3_mark_iloc_dirty+0x21/0x50
 [<c0169bbd>] ext3_mark_inode_dirty+0x29/0x34
 [<c0169c9b>] ext3_dirty_inode+0xd3/0x14c
 [<c0154809>] __mark_inode_dirty+0x39/0xec
 [<c014fab4>] update_atime+0x8c/0x98
 [<c0145b74>] link_path_walk+0x698/0x8c0
 [<c0169ca7>] ext3_dirty_inode+0xdf/0x14c
 [<c0147e53>] vfs_follow_link+0x12f/0x1a4
 [<c0170df6>] ext3_follow_link+0x16/0x20
 [<c0145b81>] link_path_walk+0x6a5/0x8c0
 [<c0146074>] path_lookup+0x128/0x134
 [<c01461af>] __user_walk+0x2f/0x4c
 [<c0141d62>] vfs_stat+0x1a/0x44
 [<c0142248>] sys_stat64+0x14/0x2c
 [<c0108b03>] syscall_call+0x7/0xb

Code: 0f 0b ea 02 60 16 29 c0 83 c4 14 8b 4d 08 8b 45 0c ff 49 04
 <6>note: bash[227] exited with preempt_count 2
Debug: sleeping function called from illegal context at
include/asm/semaphore.h:
119
Call Trace:
 [<c011293c>] __might_sleep+0x54/0x58
 [<c0114fdd>] acquire_console_sem+0x2d/0x4c
 [<c01d7d3d>] console_callback+0x9/0xb8
 [<c011f8f4>] flush_workqueue+0xfc/0x1a8
 [<c01d7d34>] console_callback+0x0/0xb8
 [<c0111860>] default_wake_function+0x0/0x34
 [<c0111860>] default_wake_function+0x0/0x34
 [<c011fbd5>] flush_scheduled_work+0xd/0x14
 [<c01c8f24>] release_dev+0x544/0x558
 [<c01270b6>] free_hot_page+0xa/0x10
 [<c012b060>] __page_cache_release+0x80/0x88
 [<c0136c16>] free_page_and_swap_cache+0x52/0x5c
 [<c012709e>] free_hot_cold_page+0xc6/0xd4
 [<c01c92de>] tty_release+0x2a/0x68
 [<c013b2d7>] __fput+0x3b/0x104
 [<c013b296>] fput+0x16/0x1c
 [<c0139ef1>] filp_close+0x99/0xa8
 [<c01159dc>] put_files_struct+0x58/0xc0
 [<c01163a8>] do_exit+0x19c/0x3d8
 [<c01091b7>] die+0x73/0x74
 [<c01094d0>] do_invalid_op+0x0/0xc0
 [<c0109584>] do_invalid_op+0xb4/0xc0
 [<c01722f7>] do_get_write_access+0x3f3/0x530
 [<c0110fe8>] try_to_wake_up+0x100/0x10c
 [<c011187d>] default_wake_function+0x1d/0x34
 [<c01118c7>] __wake_up_common+0x33/0x4c
 [<c0111900>] __wake_up+0x20/0x40
 [<c0108c85>] error_code+0x2d/0x38
 [<c01722f7>] do_get_write_access+0x3f3/0x530
 [<c0172487>] journal_get_write_access+0x53/0x78
 [<c01695df>] ext3_do_update_inode+0x21f/0x3e0
 [<c0169b15>] ext3_reserve_inode_write+0x31/0xb0
 [<c0169ab5>] ext3_mark_iloc_dirty+0x21/0x50
 [<c0169bbd>] ext3_mark_inode_dirty+0x29/0x34
 [<c0169c9b>] ext3_dirty_inode+0xd3/0x14c
 [<c0154809>] __mark_inode_dirty+0x39/0xec
 [<c014fab4>] update_atime+0x8c/0x98
 [<c0145b74>] link_path_walk+0x698/0x8c0
 [<c0169ca7>] ext3_dirty_inode+0xdf/0x14c
 [<c0147e53>] vfs_follow_link+0x12f/0x1a4
 [<c0170df6>] ext3_follow_link+0x16/0x20
 [<c0145b81>] link_path_walk+0x6a5/0x8c0
 [<c0146074>] path_lookup+0x128/0x134
 [<c01461af>] __user_walk+0x2f/0x4c
 [<c0141d62>] vfs_stat+0x1a/0x44
 [<c0142248>] sys_stat64+0x14/0x2c
 [<c0108b03>] syscall_call+0x7/0xb




--
Burton Windle                           burton@fint.org
Linux: the "grim reaper of innocent orphaned children."
          from /usr/src/linux-2.4.18/init/main.c:461

Burton Windle wrote:
> 
> I guess this could be filed under the 'shot myself in the foot'
section,
> but I figured I'd report it anyways..
> 
> Kernel 2.5.50-bk6, x86, preempt, PIIX IDE, ext3 fs.
> 
> I dd'ed the first part of a ext3 partition to tmp, then mounted it via
> loopback. (the image passed a fsck, except for warning about corrupt part.
> table or superblock)
Well that is very cruel of you, but a good and robust filesystem
should survive such abuse.
>  I tried to 'cd' into a directory within that mount,
> and got this:
> 
> EXT3 FS 2.4-0.9.16, 02 Dec 2001 on loop(7,0), internal journal
> EXT3-fs: mounted filesystem with ordered data mode.
> Assertion failure in do_get_write_access() at fs/jbd/transaction.c:746:
"handle-
> >h_buffer_credits > 0"
OK, I think I see what happened.

In ext3_dirty_inode(), we open a transaction which reserves just
a single disk block.  Because that is all we expect to write.

But when you get all the way down to ext3_do_upodate_inode(),
the corrupted inode data leads the filesytem to think that
the file has a size larger than 2G.

This triggers the logic in ext3_do_update_inode() which updates
the superblock to say "this filesystem now has files which are
larger than 2G".

But that requires a journalled superblock write.  We didn't
reserve a second block in the transaction for that, and blam.

A robust fix for this is to update all callers of ext3_do_update_inode()
to reserve an additional block for that eventuality.