[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: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Mon, 20 Oct 2008 17:05:22 +1100
In-reply-to: <20081020052929.GN31761@disturbed>
Mail-followup-to: Lachlan McIlroy <lachlan@xxxxxxx>, xfs-oss <xfs@xxxxxxxxxxx>
References: <48F6FCB7.6050905@xxxxxxx> <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>
User-agent: Mutt/1.5.18 (2008-05-17)
On Mon, Oct 20, 2008 at 04:29:29PM +1100, Dave Chinner wrote:
> On Mon, Oct 20, 2008 at 02:37:42PM +1000, Lachlan McIlroy wrote:
> > Dave Chinner wrote:
> >> On Mon, Oct 20, 2008 at 12:37:13PM +1000, Lachlan McIlroy wrote:
> >>> I also hit this panic where we have taken a reference on an inode
> >>> that has I_CLEAR set.  I suspect we've made it into xfs_iget_cache_hit()
> >>
> >> I don't think there is an iput() in that path.  The only iput() call
> >> should be the IRELE() I added to xfs_iget_cache_miss(). Can you make
> >> sure the compiler is not inlining functions so we can pin-point
> >> where the iput() call is coming from? (i.e. static > STATIC on the
> >> hit/miss functions)
> > Just disassembled xfs_iget() and xfs_iget_cache_miss() has been inlined
> > and we're calling the IRELE() at the end of that function.
> Ok, that makes more sense.
> >>> and found an inode with XFS_IRECLAIMABLE set and since we don't call
> >>> igrab() we don't do the I_CLEAR check.
> >>
> >> In that case, we call inode_init_always() instead which sets the
> >> state to I_NEW and the reference count to 1. In the error case,
> >> the inode will have already been freed and we make
> > We don't set inode->i_state to i_NEW.  We're stuffing XFS_INEW into
> > the XFS inode's i_flags field and not removing the I_CLEAR from the
> > linux inode.  Note that inode_init_always() doesn't touch i_state.
> Yeah, xfs_setup_inode() is what is doing:
>       inode->i_state = I_NEW|I_LOCK;
> which happens after the cache miss has been processed.
> Ok, so the initialisation code needs to clear іnode->i_state
> during allocation so that iput() does not complain. The i_state
> field is not accessed by anything until the inode is inserted
> into the superblock lists, so it should be safe to zero it
> in xfs_inode_alloc(). I missed that new_inode() returns an
> inode with a zeroed i_state....

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?


Dave Chinner

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