From: Mark Tinguely <tinguely@sgi.com>
To: Dave Chinner <david@fromorbit.com>
Cc: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: shutdown filesystem if xfs_perag_get fails
Date: Tue, 23 Apr 2013 08:48:01 -0500 [thread overview]
Message-ID: <51769111.3050103@sgi.com> (raw)
In-Reply-To: <20130422233033.GK30622@dastard>
On 04/22/13 18:30, Dave Chinner wrote:
> On Mon, Apr 22, 2013 at 10:11:39AM -0500, Mark Tinguely wrote:
>> #6 [ffff880135603980] _xfs_buf_find at ffffffffa01a7fef [xfs]
>> #7 [ffff8801356039f0] xfs_buf_get at ffffffffa01a824a [xfs]
>> #8 [ffff880135603a30] xfs_buf_read at ffffffffa01a83a4 [xfs]
>> #9 [ffff880135603a60] xlog_recover_inode_pass2 at ffffffffa0193629 [xfs]
>
> So it's the same problem as this bug fix addresses:
>
> commit 10616b806d1d7835b1d23b8d75ef638f92cb98b6
> Author: Dave Chinner<dchinner@redhat.com>
> Date: Mon Jan 21 23:53:52 2013 +1100
>
> xfs: fix _xfs_buf_find oops on blocks beyond the filesystem end
>
> When _xfs_buf_find is passed an out of range address, it will fail
> to find a relevant struct xfs_perag and oops with a null
> dereference. This can happen when trying to walk a filesystem with a
> metadata inode that has a partially corrupted extent map (i.e. the
> block number returned is corrupt, but is otherwise intact) and we
> try to read from the corrupted block address.
>
> In this case, just fail the lookup. If it is readahead being issued,
> it will simply not be done, but if it is real read that fails we
> will get an error being reported. Ideally this case should result
> in an EFSCORRUPTED error being reported, but we cannot return an
> error through xfs_buf_read() or xfs_buf_get() so this lookup failure
> may result in ENOMEM or EIO errors being reported instead.
>
> Signed-off-by: Dave Chinner<dchinner@redhat.com>
> Reviewed-by: Brian Foster<bfoster@redhat.com>
> Reviewed-by: Ben Myers<bpm@sgi.com>
> Signed-off-by: Ben Myers<bpm@sgi.com>
>
>> The recovery value is bad and is a problem on its own, but XFS does
>> not verify the validity of ag number when doing a xfs_perag_get().
>
> Right, that's what the above fix does, but it can't be done on older
> kernels because grwofs relies on being able to get buffers beyond
> the existing filesystem limits...
>
> Cheers,
>
> Dave.
Thank-you, that make sense.
I still do not like assuming xfs_perag_get() will always return a valid
perag pointer.
--Mark.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2013-04-23 13:47 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130419204102.736961610@sgi.com>
2013-04-21 17:41 ` [PATCH] xfs: shutdown filesystem if xfs_perag_get fails Mark Tinguely
2013-04-21 21:55 ` Eric Sandeen
2013-04-22 13:45 ` Mark Tinguely
2013-04-22 14:32 ` Eric Sandeen
2013-04-22 15:11 ` Mark Tinguely
2013-04-22 23:30 ` Dave Chinner
2013-04-23 13:48 ` Mark Tinguely [this message]
2013-04-23 15:54 ` Chandra Seetharaman
2013-04-23 20:49 ` Dave Chinner
2013-04-25 22:41 ` Chandra Seetharaman
2013-04-26 1:32 ` Dave Chinner
2013-04-26 15:32 ` Mark Tinguely
2013-04-26 16:07 ` Ben Myers
2013-04-29 22:30 ` Dave Chinner
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=51769111.3050103@sgi.com \
--to=tinguely@sgi.com \
--cc=david@fromorbit.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 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.