From: Eric Sandeen <sandeen@sandeen.net>
To: Dave Chinner <david@fromorbit.com>, xfs@oss.sgi.com
Subject: Re: [PATCH 1/2] xfs: don't leak EFSBADCRC to userspace
Date: Mon, 03 Mar 2014 11:34:35 -0600 [thread overview]
Message-ID: <5314BD2B.1010904@sandeen.net> (raw)
In-Reply-To: <1393825194-1719-2-git-send-email-david@fromorbit.com>
On 3/2/14, 11:39 PM, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> While the verifier reoutines may return EFSBADCRC when a buffer ahs
> a bad CRC, we need to translate that to EFSCORRUPTED so that the
> higher layers treat the error appropriately and so we return a
> consistent error to userspace. This fixes a xfs/005 regression.
Can you say a little more about the philosophy here?
xfs/005 regresses because it expects "structure needs cleaning"
So if we instead return our (icky) CRC error code, we get something else.
But it is truly a different root cause.
So the goal is to NEVER leak EFSBADCRC to userspace? Maybe a comment
above that error definition would help document that.
And I'm bit worried that we'll leak more in the future if things changed,
or if things got missed here. Everything you have here looks fine, but
it's not obvious that every path has been caught; it seems a bit random.
I know we _just_ merged my "differentiator" patches, but I wonder if
it would be better to add XFS_BSTATE_BADCRC to b_state or some other
field, and go back to always assigning EFSCORRUPTED. What do you think?
When I wrote those I wasn't thinking about keeping it all internal
to the filesystem.
-Eric
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
> fs/xfs/xfs_mount.c | 3 +++
> fs/xfs/xfs_symlink.c | 4 ++++
> fs/xfs/xfs_trans_buf.c | 11 +++++++++++
> 3 files changed, 18 insertions(+)
>
> diff --git a/fs/xfs/xfs_mount.c b/fs/xfs/xfs_mount.c
> index f96c056..993cb19 100644
> --- a/fs/xfs/xfs_mount.c
> +++ b/fs/xfs/xfs_mount.c
> @@ -314,6 +314,9 @@ reread:
> error = bp->b_error;
> if (loud)
> xfs_warn(mp, "SB validate failed with error %d.", error);
> + /* bad CRC means corrupted metadata */
> + if (error == EFSBADCRC)
> + error = EFSCORRUPTED;
> goto release_buf;
> }
>
> diff --git a/fs/xfs/xfs_symlink.c b/fs/xfs/xfs_symlink.c
> index 14e58f2..5fda189 100644
> --- a/fs/xfs/xfs_symlink.c
> +++ b/fs/xfs/xfs_symlink.c
> @@ -80,6 +80,10 @@ xfs_readlink_bmap(
> if (error) {
> xfs_buf_ioerror_alert(bp, __func__);
> xfs_buf_relse(bp);
> +
> + /* bad CRC means corrupted metadata */
> + if (error == EFSBADCRC)
> + error = EFSCORRUPTED;
> goto out;
> }
> byte_cnt = XFS_SYMLINK_BUF_SPACE(mp, byte_cnt);
> diff --git a/fs/xfs/xfs_trans_buf.c b/fs/xfs/xfs_trans_buf.c
> index 647b6f1..b8eef05 100644
> --- a/fs/xfs/xfs_trans_buf.c
> +++ b/fs/xfs/xfs_trans_buf.c
> @@ -275,6 +275,10 @@ xfs_trans_read_buf_map(
> XFS_BUF_UNDONE(bp);
> xfs_buf_stale(bp);
> xfs_buf_relse(bp);
> +
> + /* bad CRC means corrupted metadata */
> + if (error == EFSBADCRC)
> + error = EFSCORRUPTED;
> return error;
> }
> #ifdef DEBUG
> @@ -338,6 +342,9 @@ xfs_trans_read_buf_map(
> if (tp->t_flags & XFS_TRANS_DIRTY)
> xfs_force_shutdown(tp->t_mountp,
> SHUTDOWN_META_IO_ERROR);
> + /* bad CRC means corrupted metadata */
> + if (error == EFSBADCRC)
> + error = EFSCORRUPTED;
> return error;
> }
> }
> @@ -375,6 +382,10 @@ xfs_trans_read_buf_map(
> if (tp->t_flags & XFS_TRANS_DIRTY)
> xfs_force_shutdown(tp->t_mountp, SHUTDOWN_META_IO_ERROR);
> xfs_buf_relse(bp);
> +
> + /* bad CRC means corrupted metadata */
> + if (error == EFSBADCRC)
> + error = EFSCORRUPTED;
> return error;
> }
> #ifdef DEBUG
>
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2014-03-03 17:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-03 5:39 [PATCH 0/2] xfs: fixes for for-next Dave Chinner
2014-03-03 5:39 ` [PATCH 1/2] xfs: don't leak EFSBADCRC to userspace Dave Chinner
2014-03-03 17:34 ` Eric Sandeen [this message]
2014-03-03 22:13 ` Dave Chinner
2014-03-03 22:20 ` Eric Sandeen
2014-03-03 22:31 ` Dave Chinner
2014-03-03 17:44 ` Brian Foster
2014-03-03 22:29 ` Dave Chinner
2014-03-04 1:20 ` Brian Foster
2014-03-04 4:32 ` Dave Chinner
2014-03-04 14:01 ` Brian Foster
2014-03-05 15:48 ` Brian Foster
2014-03-03 5:39 ` [PATCH 2/2] xfs: use NOIO contexts for vm_map_ram Dave Chinner
2014-03-05 16:58 ` Christoph Hellwig
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=5314BD2B.1010904@sandeen.net \
--to=sandeen@sandeen.net \
--cc=david@fromorbit.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.