[Top] [All Lists]

Re: 2.6.31 xfs_fs_destroy_inode: cannot reclaim

To: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Subject: Re: 2.6.31 xfs_fs_destroy_inode: cannot reclaim
From: Patrick Schreurs <patrick@xxxxxxxxxxxxxxxx>
Date: Tue, 06 Oct 2009 11:04:13 +0200
Cc: Bas Couwenberg <bas@xxxxxxxxxxxxxxxx>, Tommy van Leeuwen <tommy@xxxxxxxxxxxxxxxx>, XFS List <xfs@xxxxxxxxxxx>
In-reply-to: <20091005214348.GA15448@xxxxxxxxxxxxx>
References: <20090930124104.GA7463@xxxxxxxxxxxxx> <4AC60D27.9060703@xxxxxxxxxxxxxxxx> <20091005214348.GA15448@xxxxxxxxxxxxx>
User-agent: Thunderbird (Windows/20090812)
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

commit 2f0ffb7ef75a9ad6140899f6d4df45e8a73a013e
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
    from iget_locked().

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


Patrick Schreurs

<Prev in Thread] Current Thread [Next in Thread>