Re: 2.6.19-rc2-mm1

Cedric Le Goater
2006-10-17T16:07:40Z

Andy Whitcroft wrote:
> Seeing this on a couple of x86_64's so far, probabally widespread:
>
> BUG: warning at fs/inode.c:1389/i_size_write()
>
> elm3b6:
>
> Call Trace:
> [<ffffffff8028207d>] i_size_write+0x51/0x73
> [<ffffffff8028ddfb>] generic_commit_write+0x35/0x49
> [<ffffffff802e78d1>] ext2_commit_chunk+0x32/0x6d
> [<ffffffff802e86a0>] ext2_make_empty+0x160/0x179
> [<ffffffff802eb734>] ext2_mkdir+0xb5/0x121
> [<ffffffff80278926>] vfs_mkdir+0x6a/0xaa
> [<ffffffff80278a12>] sys_mkdirat+0xac/0xfd
> [<ffffffff80272607>] vfs_stat+0x14/0x16
> [<ffffffff8021b703>] sys32_stat64+0x1a/0x34
> [<ffffffff80278a76>] sys_mkdir+0x13/0x15
> [<ffffffff8021b212>] ia32_sysret+0x0/0xa
>
> This first one does not look so unreasonable, the inode is new and has
> not yet been instantiated? But I'm no fs locking expert ...

I get something similar on x86 :

BUG: warning at fs/inode.c:1389/i_size_write()
[<c0102eb1>] dump_trace+0x63/0x1bf
[<c010301f>] show_trace_log_lvl+0x12/0x25
[<c0103559>] show_trace+0xd/0x10
[<c01035d0>] dump_stack+0x16/0x18
[<c0156c6f>] i_size_write+0x39/0x54
[<c0162050>] generic_commit_write+0x55/0x6b
[<c018fd0f>] ext2_commit_chunk+0x20/0x55
[<c018ffc6>] ext2_make_empty+0x14b/0x161
[<c0192d1d>] ext2_mkdir+0xa0/0xfe
[<c014db69>] vfs_mkdir+0x5a/0x9d
[<c014fb43>] sys_mkdirat+0x85/0xbb
[<c014fb89>] sys_mkdir+0x10/0x12
[<c01027fc>] syscall_call+0x7/0xb
DWARF2 unwinder stuck at syscall_call+0x7/0xb

It happens only once, when a first directory is created on / (ext2).

C,