All of lore.kernel.org
 help / color / mirror / Atom feed
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


  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.