Re: 2.6.31 xfs_fs_destroy_inode: cannot reclaim

From: Patrick Schreurs <patrick@news-service.com>
To: Christoph Hellwig <hch@infradead.org>
Cc: Tommy van Leeuwen <tommy@news-service.com>,
	Bas Couwenberg <bas@news-service.com>, XFS List <xfs@oss.sgi.com>
Subject: Re: 2.6.31 xfs_fs_destroy_inode: cannot reclaim
Date: Tue, 06 Oct 2009 11:04:13 +0200	[thread overview]
Message-ID: <4ACB080D.3010708@news-service.com> (raw)
In-Reply-To: <20091005214348.GA15448@infradead.org>

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@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

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs