On Tue, 19 Dec 2006 18:22:03 -0800
Suzuki <[EMAIL PROTECTED]> wrote:

> 
> Andrew Morton wrote:
> > On Tue, 19 Dec 2006 17:58:12 -0800
> > Suzuki <[EMAIL PROTECTED]> wrote:
> > 
> > 
> >>* Fix the kmalloc flags used from within ext3, when we have an active 
> >>journal handle
> >>
> >>    If we do a kmalloc with GFP_KERNEL on system running low on memory, 
> >> with an active journal handle, we might end up in cleaning up the fs cache 
> >> flushing dirty inodes for some other filesystem. This would cause hitting 
> >> a J_ASSERT() in :
> > 
> > 
> > The change might be needed (haven't looked at it yet).  But I'd like to see
> > the full BUG trace, please.  To see the callchain.
> 
> Here is the call trace which was hit by one of our test teams. This was 
> from fs/ext3/xattr.c. While looking for similar calls I found the others 
> described in the patch.
> 
> Assertion failure in journal_start() at fs/jbd/transaction.c:274: "handle-
>  >h_transaction->t_journal == journal"
> kernel BUG at fs/jbd/transaction.c:274!
> illegal operation: 0001 [#1]
> CPU:    0    Not tainted (2.6.5-7.282-s390x SLES9_SP3_BRANCH-20061031152356)
> Process dbench (pid: 14070, task: 00000000025617f0, ksp: 0000000001057630)
> Krnl PSW : 0700000180000000 0000000008837b38 (journal_start+0x90/0x15c 
> [jbd])
> Krnl GPRS: 0000000000000000 0000000000507fc0 000000000000002b 
> 0000000001056d80
>             0000000008837b36 0000000000002885 0000000008841da6 
> 0000000000000000
>             00000000001bfaa0 0000000003483d08 0000000000000002 
> 0000000007a8bda0
>             0000000008833000 00000000088a7d08 0000000008837b36 
> 0000000001056e80
> Krnl Code: 00 00 58 10 b0 0c a7 1a 00 01 b9 04 00 2b 50 10 b0 0c e3 40
> Call Trace:
>   [<00000000088a30fc>] ext3_journal_start+0x8c/0xa4 [ext3]
>   [<0000000008896822>] ext3_dirty_inode+0x3a/0xe0 [ext3]
>   [<00000000001ca362>] __mark_inode_dirty+0x1ae/0x1c8
>   [<00000000001bfaa0>] iput+0xbc/0xf0
>   [<00000000001bdcca>] prune_dcache+0x29e/0x584
>   [<00000000001bdfe4>] shrink_dcache_memory+0x34/0x54
>   [<000000000017b100>] shrink_slab+0x15c/0x250
>   [<000000000017b6e4>] try_to_free_pages+0x1c0/0x2a4
>   [<0000000000170276>] __alloc_pages+0x2ba/0x4e0
>   [<000000000017059a>] __get_free_pages+0x4e/0x8c
>   [<0000000000174ea2>] cache_alloc_refill+0x2a6/0x868
>   [<0000000000175540>] __kmalloc+0xdc/0xe0
>   [<00000000088a4e62>] ext3_xattr_set_handle+0x114a/0x174c [ext3]
>   [<00000000088a54e4>] ext3_xattr_set+0x80/0xd0 [ext3]
>   [<00000000088a6312>] ext3_xattr_user_set+0xce/0xe4 [ext3]
>   [<00000000088a5f1e>] ext3_setxattr+0x17e/0x18c [ext3]
>   [<00000000001c88e6>] setxattr+0x14a/0x234
>   [<00000000001c8a80>] sys_fsetxattr+0xb0/0x110
>   [<000000000011fc10>] sysc_noemu+0x10/0x16

How did we get from iput() into __mark_inode_dirty()?  I can't see it in
mainline, nor in 2.6.5 which you appear to be using...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to