From: Brian Foster <bfoster@redhat.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 2/2] libxfs: fix crc field handling in xfs_sb_to/from_disk
Date: Tue, 17 Jun 2014 11:05:11 -0400 [thread overview]
Message-ID: <20140617150510.GD8905@bfoster.bfoster> (raw)
In-Reply-To: <1402960461-27881-3-git-send-email-sandeen@redhat.com>
On Mon, Jun 16, 2014 at 06:14:21PM -0500, Eric Sandeen wrote:
> If we xfs_mdrestore an image from a non-crc filesystem, lo
> and behold the restored image has gained a CRC:
>
> # db/xfs_metadump.sh -o /dev/sdc1 - | xfs_mdrestore - test.img
> # xfs_db -c "sb 0" -c "p crc" /dev/sdc1
> crc = 0 (correct)
> # xfs_db -c "sb 0" -c "p crc" test.img
> crc = 0xb6f8d6a0 (correct)
>
> This is because xfs_sb_from_disk doesn't fill in sb_crc,
> but xfs_sb_to_disk(XFS_SB_ALL_BITS) does write the in-memory
> CRC to disk - so we get uninitialized memory on disk.
>
> Fix this by always initializing sb_crc to 0 when we read
> the superblock, and masking out the CRC bit from ALL_BITS
> when we write it.
>
> This same fix has already been sent for kernelspace.
>
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> ---
Reviewed-by: Brian Foster <bfoster@redhat.com>
> libxfs/xfs_sb.c | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/libxfs/xfs_sb.c b/libxfs/xfs_sb.c
> index 7ee4612..ea89367 100644
> --- a/libxfs/xfs_sb.c
> +++ b/libxfs/xfs_sb.c
> @@ -408,6 +408,8 @@ xfs_sb_from_disk(
> to->sb_features_incompat = be32_to_cpu(from->sb_features_incompat);
> to->sb_features_log_incompat =
> be32_to_cpu(from->sb_features_log_incompat);
> + /* crc is only used on disk, not in memory; just init to 0 here. */
> + to->sb_crc = 0;
> to->sb_pad = 0;
> to->sb_pquotino = be64_to_cpu(from->sb_pquotino);
> to->sb_lsn = be64_to_cpu(from->sb_lsn);
> @@ -485,6 +487,9 @@ xfs_sb_to_disk(
> if (!fields)
> return;
>
> + /* We should never write the crc here, it's updated in the IO path */
> + fields &= ~XFS_SB_CRC;
> +
> xfs_sb_quota_to_disk(to, from, &fields);
> while (fields) {
> f = (xfs_sb_field_t)xfs_lowbit64((__uint64_t)fields);
> --
> 1.7.1
>
> _______________________________________________
> xfs mailing list
> xfs@oss.sgi.com
> http://oss.sgi.com/mailman/listinfo/xfs
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
prev parent reply other threads:[~2014-06-17 15:05 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-16 23:14 [PATCH 0/2] libxfs: two kernelspace sync-ups Eric Sandeen
2014-06-16 23:14 ` [PATCH 1/2] libxfs: don't send null bp to xfs_trans_brelse() Eric Sandeen
2014-06-17 15:04 ` Brian Foster
2014-06-16 23:14 ` [PATCH 2/2] libxfs: fix crc field handling in xfs_sb_to/from_disk Eric Sandeen
2014-06-17 15:05 ` Brian Foster [this message]
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=20140617150510.GD8905@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=sandeen@redhat.com \
--cc=xfs@oss.sgi.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox