xfs
[Top] [All Lists]

Re: [PATCH] Re: another problem with latest code drops

To: Lachlan McIlroy <lachlan@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
Subject: Re: [PATCH] Re: another problem with latest code drops
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Mon, 20 Oct 2008 17:41:33 -0400
In-reply-to: <20081020060522.GP31761@disturbed>
References: <20081016222904.GA31761@disturbed> <48F7E7BA.4070209@xxxxxxx> <20081017012141.GJ25906@disturbed> <20081017020434.GD31761@disturbed> <20081017020718.GE31761@disturbed> <48FBEED9.30609@xxxxxxx> <20081020031757.GM31761@disturbed> <48FC0B16.9090102@xxxxxxx> <20081020052929.GN31761@disturbed> <20081020060522.GP31761@disturbed>
User-agent: Mutt/1.5.18 (2008-05-17)
On Mon, Oct 20, 2008 at 05:05:22PM +1100, Dave Chinner wrote:
> On second thoughts, the inode has not been set up properly
> by this stage, so we can't really even expect to be able to
> call iput() on it. Hmmmm - maybe the only thing we can do
> here is call security_inode_free() before xfs_idestroy.
> 
> Christoph - any opinions on what the best thing to do is?

Calling destroy_inode after exporting it seems most logical.  If we want
to undo init_inode_once we should have VFS functionality taking care
of that, too.

I've implemented this including some preparatory patches dealing with
the bulkstat issue.  It's half-way trough xfsqa so far.

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