From: Brian Foster <bfoster@redhat.com>
To: Eric Sandeen <sandeen@sandeen.net>
Cc: xfs@oss.sgi.com
Subject: Re: [PATCH 03/13] xfs_repair: make CRC checking consistent in path verification
Date: Mon, 14 Sep 2015 15:18:09 -0400 [thread overview]
Message-ID: <20150914191809.GC34083@bfoster.bfoster> (raw)
In-Reply-To: <1441827251-13128-4-git-send-email-sandeen@sandeen.net>
On Wed, Sep 09, 2015 at 02:34:01PM -0500, Eric Sandeen wrote:
> verify_da_path and verify_dir2_path both take steps to
> re-compute the CRC of the block if it otherwise looks
> ok and no other changes are needed. They do this inside
> a loop, but the approach differs; verify_da_path expects
> its caller to check the first buffer prior to the loop,
> and verify_dir2_path expects its caller to check the last
> buffer after the loop.
>
> Make this consistent by semi-arbitrarily choosing to make
> verify_da_path (and its caller) match the method used by
> verify_dir2_path, and check the last buffer after the
> loop is done.
>
The code here seems Ok, but I don't think the commit log description
describes what the code is doing. I could also just have misread it.
This code is recursive and hairy enough as it is...
As I follow it, we init the cursor to the leftmost descendant in
traverse_int_dablock(). I don't see any crc verification in there. We
get into process_leaf_attr_level() and it reads and walks through the
leaf blocks, doing the crc check of each one. Each leaf block we verify
corresponds to an entry in the node block, so the verify_da_path() walks
the node entry index along until we slide over to the next node block.
At that point, we verify the crc of the current node buffer, write it
out and replace that level in the cursor with the next one. Eventually
we hit the end of the leaf block chain and call verify_final_da_path().
If I'm following all that correctly, it looks to me that before this
change we would have never verified the crc of the first node block. At
least, I can't find where that might happen. After this change, that
first node block crc is checked immediately before it's written out. But
now that the post-read check is gone, I don't see where the last node
block is crc-checked. Perhaps this should be checked in
verify_final_da_path()..?
Taking a quick look at the dir2 side, it looks like it checks the crc in
traverse_int_dir2block() and bails out on -EFSBADCRC (presumably to
rebuild the whole thing..?). As noted above, it does the pre-write crc
check and I don't see where it would check the final node block(s)
either. Hmm, this code is hairy enough it might be worth running through
a debugger or doing a targeted corruption to see if I'm missing
something...
Brian
> Signed-off-by: Eric Sandeen <sandeen@redhat.com>
> Signed-off-by: Eric Sandeen <sandeen@sandeen.net>
> ---
> repair/attr_repair.c | 24 ++++++++++++++----------
> 1 files changed, 14 insertions(+), 10 deletions(-)
>
> diff --git a/repair/attr_repair.c b/repair/attr_repair.c
> index f29a5bd..aba0782 100644
> --- a/repair/attr_repair.c
> +++ b/repair/attr_repair.c
> @@ -606,6 +606,14 @@ verify_da_path(xfs_mount_t *mp,
> ASSERT(cursor->level[this_level].dirty == 0 ||
> (cursor->level[this_level].dirty && !no_modify));
>
> + /*
> + * If block looks ok but CRC didn't match, make sure to
> + * recompute it.
> + */
> + if (!no_modify &&
> + cursor->level[this_level].bp->b_error == -EFSBADCRC)
> + cursor->level[this_level].dirty = 1;
> +
> if (cursor->level[this_level].dirty && !no_modify)
> libxfs_writebuf(cursor->level[this_level].bp, 0);
> else
> @@ -618,14 +626,6 @@ verify_da_path(xfs_mount_t *mp,
> cursor->level[this_level].hashval =
> be32_to_cpu(btree[0].hashval);
> entry = cursor->level[this_level].index = 0;
> -
> - /*
> - * We want to rewrite the buffer on a CRC error seeing as it
> - * contains what appears to be a valid node block, but only if
> - * we are fixing errors.
> - */
> - if (bp->b_error == -EFSBADCRC && !no_modify)
> - cursor->level[this_level].dirty++;
> }
> /*
> * ditto for block numbers
> @@ -1363,8 +1363,6 @@ process_leaf_attr_level(xfs_mount_t *mp,
> da_bno, dev_bno, ino);
> goto error_out;
> }
> - if (bp->b_error == -EFSBADCRC)
> - repair++;
>
> leaf = bp->b_addr;
> xfs_attr3_leaf_hdr_from_disk(mp->m_attr_geo, &leafhdr, leaf);
> @@ -1419,6 +1417,12 @@ process_leaf_attr_level(xfs_mount_t *mp,
> }
>
> current_hashval = greatest_hashval;
> + /*
> + * If block looks ok but CRC didn't match, make sure to
> + * recompute it.
> + */
> + if (!no_modify && bp->b_error == -EFSBADCRC)
> + repair++;
>
> if (repair && !no_modify)
> libxfs_writebuf(bp, 0);
> --
> 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
next prev parent reply other threads:[~2015-09-14 19:18 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-09 19:33 [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c Eric Sandeen
2015-09-09 19:33 ` [PATCH 01/13] xfs_repair: remove trace-only 'n' member from da_level_state Eric Sandeen
2015-09-14 19:17 ` Brian Foster
2015-09-09 19:34 ` [PATCH 02/13] xfs_repair: remove type from da & dir2 cursors Eric Sandeen
2015-09-14 19:18 ` Brian Foster
2015-09-09 19:34 ` [PATCH 03/13] xfs_repair: make CRC checking consistent in path verification Eric Sandeen
2015-09-14 19:18 ` Brian Foster [this message]
2015-09-09 19:34 ` [PATCH 04/13] xfs_repair: use multibuffer read routines in attr_repair.c Eric Sandeen
2015-09-14 19:18 ` Brian Foster
2015-09-14 19:24 ` Eric Sandeen
2015-09-14 19:30 ` Brian Foster
2015-09-09 19:34 ` [PATCH 05/13] xfs_repair: fix use-after-free in verify_final_dir2_path Eric Sandeen
2015-09-14 19:18 ` Brian Foster
2015-09-09 19:34 ` [PATCH 06/13] xfs_repair: add XR_DIR_TRACE to dir2.c Eric Sandeen
2015-09-14 19:18 ` Brian Foster
2015-09-09 19:34 ` [PATCH 07/13] xfs_repair: Remove BUF_PTR from attr_repair.c Eric Sandeen
2015-09-14 19:44 ` Brian Foster
2015-09-09 19:34 ` [PATCH 08/13] xfs_repair: catch bad level/depth in da node Eric Sandeen
2015-09-14 19:44 ` Brian Foster
2015-09-09 19:34 ` [PATCH 09/13] xfs_repair: better checking of v5 attributes Eric Sandeen
2015-09-14 19:44 ` Brian Foster
2015-09-23 17:53 ` Eric Sandeen
2015-09-09 19:34 ` [PATCH 10/13] xfs_repair: Remove more differences between attr & dir2 Eric Sandeen
2015-09-14 19:55 ` Brian Foster
2015-09-09 19:34 ` [PATCH 11/13] xfs_repair: whitespace & comments Eric Sandeen
2015-09-14 19:56 ` Brian Foster
2015-09-09 19:34 ` [PATCH 12/13] xfs_repair: move common dir2 and attr_repair code to da_util.c Eric Sandeen
2015-09-09 19:34 ` [PATCH 13/13] xfs_repair: Fix up warning strings in da_util.c Eric Sandeen
2015-09-14 20:06 ` Brian Foster
2015-09-14 20:11 ` Eric Sandeen
2015-09-10 9:22 ` [PATCH 0/13] xfs_repair: recombine cut&waste code in dir2.c/attr_repair.c Carlos Maiolino
2015-09-10 16:51 ` Eric Sandeen
2015-09-11 8:20 ` Carlos Maiolino
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=20150914191809.GC34083@bfoster.bfoster \
--to=bfoster@redhat.com \
--cc=sandeen@sandeen.net \
--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