From: "Darrick J. Wong" <darrick.wong@oracle.com>
To: Brian Foster <bfoster@redhat.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH] xfs: log the inode on directory sf to block format change
Date: Fri, 4 Oct 2019 08:24:08 -0700 [thread overview]
Message-ID: <20191004152408.GL13108@magnolia> (raw)
In-Reply-To: <20191004125520.7857-1-bfoster@redhat.com>
On Fri, Oct 04, 2019 at 08:55:20AM -0400, Brian Foster wrote:
> When a directory changes from shortform (sf) to block format, the sf
> format is copied to a temporary buffer, the inode format is modified
> and the updated format filled with the dentries from the temporary
> buffer. If the inode format is modified and attempt to grow the
> inode fails (due to I/O error, for example), it is possible to
> return an error while leaving the directory in an inconsistent state
> and with an otherwise clean transaction. This results in corruption
> of the associated directory and leads to xfs_dabuf_map() errors as
> subsequent lookups cannot accurately determine the format of the
> directory. This problem is reproduced occasionally by generic/475.
>
> The fundamental problem is that xfs_dir2_sf_to_block() changes the
> on-disk inode format without logging the inode. The inode is
> eventually logged by the bmapi layer in the common case, but error
> checking introduces the possibility of failing the high level
> request before this happens.
>
> Update xfs_dir2_sf_to_block() to log the inode when the on-disk
> format is changed. This ensures that any subsequent errors after the
> format has changed cause the transaction to abort.
>
> Signed-off-by: Brian Foster <bfoster@redhat.com>
> ---
> fs/xfs/libxfs/xfs_dir2_block.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/fs/xfs/libxfs/xfs_dir2_block.c b/fs/xfs/libxfs/xfs_dir2_block.c
> index 9595ced393dc..3d1e5f6d64fd 100644
> --- a/fs/xfs/libxfs/xfs_dir2_block.c
> +++ b/fs/xfs/libxfs/xfs_dir2_block.c
> @@ -1098,6 +1098,7 @@ xfs_dir2_sf_to_block(
> xfs_idata_realloc(dp, -ifp->if_bytes, XFS_DATA_FORK);
> xfs_bmap_local_to_extents_empty(dp, XFS_DATA_FORK);
> dp->i_d.di_size = 0;
> + xfs_trans_log_inode(tp, dp, XFS_ILOG_CORE);
I think the general idea looks ok, but is there any reason why we don't
log the inode in xfs_bmap_local_to_extents_empty, since it changes the
ondisk format?
Also, does xfs_attr_shortform_to_leaf have a similar problem?
--D
>
> /*
> * Add block 0 to the inode.
> --
> 2.20.1
>
next prev parent reply other threads:[~2019-10-04 15:24 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-10-04 12:55 [PATCH] xfs: log the inode on directory sf to block format change Brian Foster
2019-10-04 15:24 ` Darrick J. Wong [this message]
2019-10-04 15:51 ` Brian Foster
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191004152408.GL13108@magnolia \
--to=darrick.wong@oracle.com \
--cc=bfoster@redhat.com \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.