From: "Darrick J. Wong" <djwong@kernel.org>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-xfs@vger.kernel.org
Subject: Re: [PATCH 2/4] metadump: be careful zeroing corrupt inode forks
Date: Tue, 26 Apr 2022 17:40:27 -0700 [thread overview]
Message-ID: <20220427004027.GX17025@magnolia> (raw)
In-Reply-To: <20220426234453.682296-3-david@fromorbit.com>
On Wed, Apr 27, 2022 at 09:44:51AM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> When a corrupt inode fork is encountered, we can zero beyond the end
> of the inode if the fork pointers are sufficiently trashed. We
> should not trust the fork pointers when corruption is detected and
> skip the zeroing in this case. We want metadump to capture the
> corruption and so skipping the zeroing will give us the best chance
> of preserving the corruption in a meaningful state for diagnosis.
>
> Reported-by: Sean Caron <scaron@umich.edu>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
Hmm. I /think/ the only real change here is the addition of the
DFORK_DSIZE > LITINO warning, right? The rest is just reindenting the
loop body?
If so, LGTM.
Reviewed-by: Darrick J. Wong <djwong@kernel.org>
--D
> ---
> db/metadump.c | 49 +++++++++++++++++++++++++++++++++++++++----------
> 1 file changed, 39 insertions(+), 10 deletions(-)
>
> diff --git a/db/metadump.c b/db/metadump.c
> index a21baa2070d9..3948d36e4d5c 100644
> --- a/db/metadump.c
> +++ b/db/metadump.c
> @@ -2308,18 +2308,34 @@ process_inode_data(
> {
> switch (dip->di_format) {
> case XFS_DINODE_FMT_LOCAL:
> - if (obfuscate || zero_stale_data)
> - switch (itype) {
> - case TYP_DIR2:
> - process_sf_dir(dip);
> - break;
> + if (!(obfuscate || zero_stale_data))
> + break;
> +
> + /*
> + * If the fork size is invalid, we can't safely do
> + * anything with this fork. Leave it alone to preserve
> + * the information for diagnostic purposes.
> + */
> + if (XFS_DFORK_DSIZE(dip, mp) > XFS_LITINO(mp)) {
> + print_warning(
> +"Invalid data fork size (%d) in inode %llu, preserving contents!",
> + XFS_DFORK_DSIZE(dip, mp),
> + (long long)cur_ino);
> + break;
> + }
>
> - case TYP_SYMLINK:
> - process_sf_symlink(dip);
> - break;
> + switch (itype) {
> + case TYP_DIR2:
> + process_sf_dir(dip);
> + break;
>
> - default: ;
> - }
> + case TYP_SYMLINK:
> + process_sf_symlink(dip);
> + break;
> +
> + default:
> + break;
> + }
> break;
>
> case XFS_DINODE_FMT_EXTENTS:
> @@ -2341,6 +2357,19 @@ process_dev_inode(
> (unsigned long long)cur_ino);
> return;
> }
> +
> + /*
> + * If the fork size is invalid, we can't safely do anything with
> + * this fork. Leave it alone to preserve the information for diagnostic
> + * purposes.
> + */
> + if (XFS_DFORK_DSIZE(dip, mp) > XFS_LITINO(mp)) {
> + print_warning(
> +"Invalid data fork size (%d) in inode %llu, preserving contents!",
> + XFS_DFORK_DSIZE(dip, mp), (long long)cur_ino);
> + return;
> + }
> +
> if (zero_stale_data) {
> unsigned int size = sizeof(xfs_dev_t);
>
> --
> 2.35.1
>
next prev parent reply other threads:[~2022-04-27 0:40 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-26 23:44 [PATCH 0/4] xfsprogs: fixes and updates Dave Chinner
2022-04-26 23:44 ` [PATCH 1/4] metadump: handle corruption errors without aborting Dave Chinner
2022-04-27 0:45 ` Darrick J. Wong
2022-04-27 1:26 ` Dave Chinner
2022-04-26 23:44 ` [PATCH 2/4] metadump: be careful zeroing corrupt inode forks Dave Chinner
2022-04-27 0:40 ` Darrick J. Wong [this message]
2022-04-27 1:27 ` Dave Chinner
2022-04-26 23:44 ` [PATCH 3/4] xfs_io: add a quiet option to bulkstat Dave Chinner
2022-04-27 0:38 ` Darrick J. Wong
2022-04-26 23:44 ` [PATCH 4/4] xfsprogs: autoconf modernisation Dave Chinner
2022-04-27 0:42 ` Darrick J. Wong
2022-04-27 1:33 ` Dave Chinner
2022-05-26 18:49 ` Eric Sandeen
2022-05-26 19:44 ` Eric Sandeen
2022-05-27 1:11 ` Dave Chinner
2022-05-27 6:17 ` Christoph Hellwig
2022-05-27 17:04 ` Darrick J. Wong
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=20220427004027.GX17025@magnolia \
--to=djwong@kernel.org \
--cc=david@fromorbit.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).