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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox