public inbox for linux-xfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: xfs-oss <xfs@oss.sgi.com>
Subject: Re: [PATCH] xfs: don't ASSERT on corrupt ftype
Date: Mon, 8 Sep 2014 23:05:07 +1000	[thread overview]
Message-ID: <20140908130507.GN30012@dastard> (raw)
In-Reply-To: <540D011B.2000807@redhat.com>

On Sun, Sep 07, 2014 at 08:06:35PM -0500, Eric Sandeen wrote:
> xfs_dir3_data_get_ftype() and xfs_dir2_sf_check() get
> the file type off disk, but ASSERT if it's invalid:
> 
> 	ASSERT(type < XFS_DIR3_FT_MAX);
> 
> This might be cut & paste from the "put" functions,
> which should be checking that they've not been passed
> bad values, but we shouldn't ASSERT on bad values
> read from disk.

No, they weren't cut-n-paste from the put functions. They were
actually designed for a metadata block where bad values would not be
written to disk, and corrupted disk blocks would be detected by CRC
validation failures. So on debug kernels it's quite appropriate to
assert fail on a "should never, ever happen" condition.

Then the v4 ftype feature bit was rammed in but none of the code got
changed to reflect that the values in the ftype fields are not CRC
protected on v4 filesystems....

> diff --git a/fs/xfs/libxfs/xfs_dir2_sf.c b/fs/xfs/libxfs/xfs_dir2_sf.c
> index 5079e05..ea89250 100644
> --- a/fs/xfs/libxfs/xfs_dir2_sf.c
> +++ b/fs/xfs/libxfs/xfs_dir2_sf.c
> @@ -635,7 +635,6 @@ xfs_dir2_sf_check(
>  		offset =
>  			xfs_dir2_sf_get_offset(sfep) +
>  			dp->d_ops->data_entsize(sfep->namelen);
> -		ASSERT(dp->d_ops->sf_get_ftype(sfep) < XFS_DIR3_FT_MAX);
>  	}
>  	ASSERT(i8count == sfp->i8count);
>  	ASSERT((char *)sfep - (char *)sfp == dp->i_d.di_size);

That's a debug only function validating that the shortform directory
is internally consistent. And as the comment says:

/*
 * Check consistency of shortform directory, assert if bad.
 */

So that assert should remain because it's checking the in-memory
state immediately before, during and after modifications are made to
the directory, not when it has just been read of disk....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2014-09-08 13:05 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-08  1:06 [PATCH] xfs: don't ASSERT on corrupt ftype Eric Sandeen
2014-09-08 12:03 ` Brian Foster
2014-09-08 13:05 ` Dave Chinner [this message]
2014-09-08 13:49   ` Eric Sandeen
2014-09-08 14:02     ` Eric Sandeen
2014-09-08 22:00       ` Dave Chinner
2014-09-08 22:18 ` [PATCH V2] " Eric Sandeen

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=20140908130507.GN30012@dastard \
    --to=david@fromorbit.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