linux-xfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
> 

  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).