[Top] [All Lists]

Re: [PATCH 15/37 V3] libxfs: fix root inode handling inconsistencies

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 15/37 V3] libxfs: fix root inode handling inconsistencies
From: Christoph Hellwig <hch@xxxxxxxxxxxxx>
Date: Thu, 7 Nov 2013 00:11:59 -0800
Cc: Christoph Hellwig <hch@xxxxxxxxxxxxx>, xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <20131107045830.GN6188@dastard>
References: <1383700043-32305-1-git-send-email-david@xxxxxxxxxxxxx> <1383700043-32305-16-git-send-email-david@xxxxxxxxxxxxx> <20131106102334.GB614@xxxxxxxxxxxxx> <20131106230257.GJ6188@dastard> <20131107045830.GN6188@dastard>
User-agent: Mutt/1.5.21 (2010-09-15)
On Thu, Nov 07, 2013 at 03:58:30PM +1100, Dave Chinner wrote:
> From: Dave Chinner <dchinner@xxxxxxxxxx>
> When "mounting" a filesystem via libxfs_mount(), callers can tell
> libxfs to read the root and realtime inodes into cache. However,
> when unmounting the filesystem, libxfs_unmount() used to
> unconditionally free root inodes if they were present.
> This leads to interesting issues like in mkfs, when it handles
> creation, reading and freeing of the root and rt inodes itself.
> It, however, passes in the flag to tell libxfs_mount() to read the
> root inodes and so can result in unbalanced freeing of inodes when
> cleaning up during the unmount proceedure.
> As it turns out, nothing ever uses mp->m_rootip and so we don't need
> to read it in or free it, or even have a pointer to it in the struct
> xfs_mount. Similarly, the only user of the realtime inodes is mkfs,
> and it initialises them itself. Hence we can kill the m_rootip and
> the realtime inode mounting code.
> This leaves one user of LIBXFS_MOUNT_ROOTINOS - xfs_db - and that is
> only used to initialise the in-core superblock counter values from
> the ag header for xfs_check. Move this code to the xfs_db init
> functions so we can get rid of the mount parameter previously used
> to trigger all these behavours (LIBXFS_MOUNT_ROOTINOS) completely.
> Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>

Looks good,

Reviewed-by: Christoph Hellwig <hch@xxxxxx>

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