2.6.31 xfs_fs_destroy_inode: cannot reclaim

[Patrick Schreurs]

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 2.6.32.2)?

commit 2f0ffb7ef75a9ad6140899f6d4df45e8a73a013e
Author: Jan Kara <jack at suse.cz>
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
     from iget_locked().

     This seems to fix a corruption issue on ext3 mounted over NFS.

Thanks,

Patrick Schreurs