From: Jens Axboe <axboe@kernel.dk>
To: Dave Chinner <david@fromorbit.com>
Cc: linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: [PATCH 2/2] blkdev: check for valid request queue before issuing flush
Date: Tue, 13 Jul 2010 14:55:14 +0200 [thread overview]
Message-ID: <4C3C6232.5090509@kernel.dk> (raw)
In-Reply-To: <1279007450-10457-3-git-send-email-david@fromorbit.com>
On 2010-07-13 09:50, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> Issuing a blkdev_issue_flush() on an unconfigured loop device causes a panic as
> q->make_request_fn is not configured. This can occur when trying to mount the
> unconfigured loop device as an XFS filesystem. There are no guards that catch
> the bio before the request function is called because we don't add a payload to
> the bio. Instead, manually check this case as soon as we have a pointer to the
> queue to flush.
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
> block/blk-barrier.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/block/blk-barrier.c b/block/blk-barrier.c
> index 0d710c9..0fd766e 100644
> --- a/block/blk-barrier.c
> +++ b/block/blk-barrier.c
> @@ -319,6 +319,15 @@ int blkdev_issue_flush(struct block_device *bdev, gfp_t gfp_mask,
> if (!q)
> return -ENXIO;
>
> + /*
> + * some block devices may not have their queue correctly set up here
> + * (e.g. loop device without a backing file) and so issuing a flush
> + * here will panic. Ensure there is a request function before issuing
> + * the barrier.
> + */
> + if (!q->make_request_fn)
> + return -ENXIO;
> +
> bio = bio_alloc(gfp_mask, 0);
> bio->bi_end_io = bio_end_empty_barrier;
> bio->bi_bdev = bdev;
This may appear ugly, but I think the patch is fine since there's not
much we can do about the loop crap (outside of changing how you do
setup/configure of it).
I'll apply this, thanks.
--
Jens Axboe
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
WARNING: multiple messages have this Message-ID (diff)
From: Jens Axboe <axboe@kernel.dk>
To: Dave Chinner <david@fromorbit.com>
Cc: xfs@oss.sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/2] blkdev: check for valid request queue before issuing flush
Date: Tue, 13 Jul 2010 14:55:14 +0200 [thread overview]
Message-ID: <4C3C6232.5090509@kernel.dk> (raw)
In-Reply-To: <1279007450-10457-3-git-send-email-david@fromorbit.com>
On 2010-07-13 09:50, Dave Chinner wrote:
> From: Dave Chinner <dchinner@redhat.com>
>
> Issuing a blkdev_issue_flush() on an unconfigured loop device causes a panic as
> q->make_request_fn is not configured. This can occur when trying to mount the
> unconfigured loop device as an XFS filesystem. There are no guards that catch
> the bio before the request function is called because we don't add a payload to
> the bio. Instead, manually check this case as soon as we have a pointer to the
> queue to flush.
>
> Signed-off-by: Dave Chinner <dchinner@redhat.com>
> ---
> block/blk-barrier.c | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/block/blk-barrier.c b/block/blk-barrier.c
> index 0d710c9..0fd766e 100644
> --- a/block/blk-barrier.c
> +++ b/block/blk-barrier.c
> @@ -319,6 +319,15 @@ int blkdev_issue_flush(struct block_device *bdev, gfp_t gfp_mask,
> if (!q)
> return -ENXIO;
>
> + /*
> + * some block devices may not have their queue correctly set up here
> + * (e.g. loop device without a backing file) and so issuing a flush
> + * here will panic. Ensure there is a request function before issuing
> + * the barrier.
> + */
> + if (!q->make_request_fn)
> + return -ENXIO;
> +
> bio = bio_alloc(gfp_mask, 0);
> bio->bi_end_io = bio_end_empty_barrier;
> bio->bi_bdev = bdev;
This may appear ugly, but I think the patch is fine since there's not
much we can do about the loop crap (outside of changing how you do
setup/configure of it).
I'll apply this, thanks.
--
Jens Axboe
next prev parent reply other threads:[~2010-07-13 12:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-13 7:50 [PATCH 0/2] Graceful failures for XFS on an unconfigured loop device Dave Chinner
2010-07-13 7:50 ` Dave Chinner
2010-07-13 7:50 ` [PATCH 1/2] xfs: don't block on buffer read errors Dave Chinner
2010-07-13 7:50 ` Dave Chinner
2010-07-14 18:28 ` Christoph Hellwig
2010-07-14 18:28 ` Christoph Hellwig
2010-07-15 0:05 ` Dave Chinner
2010-07-15 0:05 ` Dave Chinner
2010-07-13 7:50 ` [PATCH 2/2] blkdev: check for valid request queue before issuing flush Dave Chinner
2010-07-13 7:50 ` Dave Chinner
2010-07-13 12:55 ` Jens Axboe [this message]
2010-07-13 12:55 ` Jens Axboe
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=4C3C6232.5090509@kernel.dk \
--to=axboe@kernel.dk \
--cc=david@fromorbit.com \
--cc=linux-kernel@vger.kernel.org \
--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.