panic: assertion: (RB_EMPTY(&ip->rec_tree) && (ip->flags & HAMMER_INODE_XDIRTY) == 0) || (!RB_EMPTY(&ip->rec_tree) && (ip->flags & HAMMER_INODE_XDIRTY) != 0) in hammer_flush_inode_done

[Matthew Dillon]

:Hello.
:Caught this while running pbulk on an Atom D510, running x86_64 kernel.
:This one is new to me and I haven't seen this one before updating the
:kernel.  The current kernel was built from source whose commit hash is
:c6aff4f7f0c74961380763de0bcb5dd49fb7faea, while the previous kernel was
:from c4ce4f88f289f77826fecf470965d7e216274018.  No hammer cleanup was
:running when it panicked.

    Hmm.  Well, the state of the tree and flags as-of the core dump
    is fine and would have passed that assertion test, so something
    changed between the assertion and the kernel core dump.

    Essentially that assertion is saying that XDIRTY should always be
    in a synchronized state against whether records exist in ip->rec_tree
    or not.

    I think you may have found a very short race condition where the
    XDIRTY flag is not perfectly in-sync with the presence of records
    on the RB tree, but I can only guess.  It's going to be very rare.

    I found one situation where this can happen.  If the frontend truncates
    a file and calls hammer_rel_mem_record() simultaniously with the backend
    finishing a flush operation on the same inode AND a direct write I/O
    is in progress (causing the frontend to block) then this case can occur.

    Here is a patch to try:

	fetch http://apollo.backplane.com/DFlyMisc/hammer25.patch

    However it may be very difficult to reproduce this bug.  What we really
    need to do here is just do a run-through on the HAMMER filesystem w/
    the patch to make sure I didn't break anything by moving the clearing
    of those flags.  I'm pretty sure it is ok but I get a bit jittery when
    I have to mess with hammer_inode->flags.

					-Matt