On Mon, Oct 24, 2011 at 3:39 AM, Amon Ott <a.ott@xxxxxxxxxxxx> wrote:
> Hi folks,
>
> we have hit a kernel bug with current ceph-client master (commit
> a2742a09568f81315e0f30021f29f14e7cd3924b), which I assume to be a Ceph bug.
Is it easily reproducible? What's the scenario?
>
> Kernel is x86-32, Ceph is running on a two node cluster over ext4. The kernel
> traces are attached, the system dies shortly after these messages. The bug is
> reproducable. I have not found anything useful in ceph bug tracker when
> searching for "fs/inode.c".
How many mds servers?
>
> Around fs/inode.c line 1375 mentioned in the trace is the iput() function:
> void iput(struct inode *inode)
> {
> if (inode) {
> BUG_ON(inode->i_state & I_CLEAR);
>
> if (atomic_dec_and_lock(&inode->i_count, &inode->i_lock))
> iput_final(inode);
> }
> }
>
> So inode->i_state seems to be incorrect when iput() is called, maybe a double
> call to iput() or a missing iget() somewhere. Is this really a Ceph bug or
> have I messed up our kernel code when merging patches?
>
What patches?
Also, the client logs could help shedding a light on the issue. You
should have dynamic debugging turned on (CONFIG_DYNAMIC_DEBUG), and
something along the lines of:
# mount -t debugfs none /sys/kernel/debug
# echo 'module ceph +p' > /sys/kernel/debug/dynamic_debug/control
# echo 'module libceph +p' > /sys/kernel/debug/dynamic_debug/control
Thanks,
Yehuda
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
