xfs
[Top] [All Lists]

Re: [PATCH] sanitize xfs_initialize_vnode

To: Christoph Hellwig <hch@xxxxxx>
Subject: Re: [PATCH] sanitize xfs_initialize_vnode
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 24 Jul 2008 16:16:15 +1000
Cc: xfs@xxxxxxxxxxx
In-reply-to: <20080723195110.GA6645@xxxxxx>
Mail-followup-to: Christoph Hellwig <hch@xxxxxx>, xfs@xxxxxxxxxxx
References: <20080502105215.GA17870@xxxxxx> <20080723195110.GA6645@xxxxxx>
Sender: xfs-bounce@xxxxxxxxxxx
User-agent: Mutt/1.5.18 (2008-05-17)
On Wed, Jul 23, 2008 at 09:51:10PM +0200, Christoph Hellwig wrote:
> On Fri, May 02, 2008 at 12:52:15PM +0200, Christoph Hellwig wrote:
> > Sanitize setting up the Linux indode.
> > 
> > Setting up the xfs_inode <-> inode link is opencoded in xfs_iget_core
> > now because that's the only place it needs to be done,
> > xfs_initialize_vnode is renamed to xfs_setup_inode and loses all
> > superflous paramaters.  The check for I_NEW is removed because it always
> > is true and the di_mode check moves into xfs_iget_core because it's only
> > needed there.
> > 
> > xfs_set_inodeops and xfs_revalidate_inode are merged into
> > xfs_setup_inode and the whole things is moved into xfs_iops.c where it
> > belongs.
> 
> Rediffed to apply ontop of Dave's and my vnode helper cleanups:

Looks good and has been passing testing here for the past week...

One question, though:

> +     }
> +
> +     xfs_iflags_clear(ip, XFS_INEW);
> +     barrier();
> +
> +     unlock_new_inode(inode);
> +}

Do we still need that barrier()? Or has the reason for it
existing been lost in the mists of time? Regardless, it was
there before so this is not a reason to stop the patch from
going in...

Cheers,

Dave.

-- 
Dave Chinner
david@xxxxxxxxxxxxx


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