Christoph Hellwig wrote:
It helps a bit, but not so much. I suspect it could be a double free
of an inode, and I have identified a possible race window that could
explain it. But all the traces are really weird and I think only show
later symptoms of something that happened earlier. I'll come up with
a patch for the race window ASAP, but could you in the meantime turn on
CONFIG_XFS_DEBUG for the test kernel to see if it triggers somehwere
and additionally apply the tiny patch below for additional debugging?
Will try this.
Could this by any change be releated (from 22.214.171.124)?
Author: Jan Kara <jack@xxxxxxx>
Date: Mon Sep 21 17:01:06 2009 -0700
fs: make sure data stored into inode is properly seen before
unlocking new inode
commit 580be0837a7a59b207c3d5c661d044d8dd0a6a30 upstream.
In theory it could happen that on one CPU we initialize a new inode
but clearing of I_NEW | I_LOCK gets reordered before some of the
initialization. Thus on another CPU we return not fully uptodate inode
This seems to fix a corruption issue on ext3 mounted over NFS.