On one of our nodes we got the following stack trace: Feb 19 16:55:53 nafhh kernel: updatedb D 000000000000000f 0 32087 32081 0x00000080 Feb 19 16:55:53 nafhh kernel: ffff880852d13a88 0000000000000082 0000000000000000 ffffffffa00bfe13 Feb 19 16:55:53 nafhh kernel: 0000000000000050 0000000300000001 000d5a7576495a7a 0000000000000286 Feb 19 16:55:53 nafhh kernel: 0000000000000286 00000001dfd51213 ffff8810207c5068 ffff880852d13fd8 Feb 19 16:55:53 nafhh kernel: Call Trace: Feb 19 16:55:53 nafhh kernel: [<ffffffffa00bfe13>] ? ext4_mark_inode_dirty+0x83/0x1d0 [ext4] Feb 19 16:55:53 nafhh kernel: [<ffffffffa029b1e4>] ? __rpc_sleep_on_priority+0xf4/0x330 [sunrpc] Feb 19 16:55:53 nafhh kernel: [<ffffffffa029a5b0>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc] Feb 19 16:55:53 nafhh kernel: [<ffffffffa029a5f2>] rpc_wait_bit_killable+0x42/0xa0 [sunrpc] Feb 19 16:55:53 nafhh kernel: [<ffffffff8154ca7f>] __wait_on_bit+0x5f/0x90 Feb 19 16:55:53 nafhh kernel: [<ffffffffa0294217>] ? xprt_reserve_xprt+0x87/0x110 [sunrpc] Feb 19 16:55:53 nafhh kernel: [<ffffffffa029a5b0>] ? rpc_wait_bit_killable+0x0/0xa0 [sunrpc] Feb 19 16:55:53 nafhh kernel: [<ffffffff8154cb28>] out_of_line_wait_on_bit+0x78/0x90 Feb 19 16:55:53 nafhh kernel: [<ffffffff810a7220>] ? wake_bit_function+0x0/0x50 Feb 19 16:55:53 nafhh kernel: [<ffffffffa029ab35>] __rpc_execute+0xf5/0x350 [sunrpc] Feb 19 16:55:53 nafhh kernel: [<ffffffff810a7027>] ? bit_waitqueue+0x17/0xd0 Feb 19 16:55:53 nafhh kernel: [<ffffffffa029adf1>] rpc_execute+0x61/0xa0 [sunrpc] Feb 19 16:55:53 nafhh kernel: [<ffffffffa0291475>] rpc_run_task+0x75/0x90 [sunrpc] Feb 19 16:55:53 nafhh kernel: [<ffffffffa0291592>] rpc_call_sync+0x42/0x70 [sunrpc] Feb 19 16:55:53 nafhh kernel: [<ffffffffa035cf2e>] _nfs4_call_sync+0x3e/0x40 [nfs] Feb 19 16:55:53 nafhh kernel: [<ffffffffa035574c>] _nfs4_proc_getattr+0xac/0xc0 [nfs] Feb 19 16:55:53 nafhh kernel: [<ffffffffa0358796>] nfs4_proc_getattr+0x56/0x80 [nfs] Feb 19 16:55:53 nafhh kernel: [<ffffffffa033e293>] __nfs_revalidate_inode+0xe3/0x220 [nfs] Feb 19 16:55:53 nafhh kernel: [<ffffffffa033f12e>] nfs_getattr+0xde/0x210 [nfs] Feb 19 16:55:53 nafhh kernel: [<ffffffff811a0391>] vfs_getattr+0x51/0x80 Feb 19 16:55:53 nafhh kernel: [<ffffffff811a01d4>] ? cp_new_stat+0xe4/0x100 Feb 19 16:55:53 nafhh kernel: [<ffffffff811a0424>] vfs_fstatat+0x64/0xa0 Feb 19 16:55:53 nafhh kernel: [<ffffffff811a04ce>] vfs_lstat+0x1e/0x20 Feb 19 16:55:53 nafhh kernel: [<ffffffff811a04f4>] sys_newlstat+0x24/0x50 Feb 19 16:55:53 nafhh kernel: [<ffffffff81556627>] ? system_call_after_swapgs+0x187/0x220 Feb 19 16:55:53 nafhh kernel: [<ffffffff81556620>] ? system_call_after_swapgs+0x180/0x220 Feb 19 16:55:53 nafhh kernel: [<ffffffff810eeef7>] ? audit_syscall_entry+0x1d7/0x200 Feb 19 16:55:53 nafhh kernel: [<ffffffff8155660b>] ? system_call_after_swapgs+0x16b/0x220 Feb 19 16:55:53 nafhh kernel: [<ffffffff81556604>] ? system_call_after_swapgs+0x164/0x220 Feb 19 16:55:53 nafhh kernel: [<ffffffff815565fd>] ? system_call_after_swapgs+0x15d/0x220 Feb 19 16:55:53 nafhh kernel: [<ffffffff815565f6>] ? system_call_after_swapgs+0x156/0x220 Feb 19 16:55:53 nafhh kernel: [<ffffffff815565ef>] ? system_call_after_swapgs+0x14f/0x220 Feb 19 16:55:53 nafhh kernel: [<ffffffff815566d6>] system_call_fastpath+0x16/0x1b Feb 19 16:55:53 nafhh kernel: [<ffffffff8155656a>] ? system_call_after_swapgs+0xca/0x220 I am surprised, that top of the stack trace is in ext4 module. Can some one put a light on it? Thanks in advance, Tigran. -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
