All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Snitzer <snitzer@redhat.com>
To: axboe@kernel.dk
Cc: linux-kernel@vger.kernel.org, martin.petersen@oracle.com,
	hch@infradead.org, mst@redhat.com, rusty@rustcorp.com.au,
	dm-devel@redhat.com
Subject: [PATCH] virtio_blk: fix defaults for max_hw_sectors and max_segment_size
Date: Thu, 20 Nov 2014 14:00:59 -0500	[thread overview]
Message-ID: <20141120190058.GA31214@redhat.com> (raw)

virtio_blk incorrectly established -1U as the default for these
queue_limits.  Set these limits to sane default values to avoid crashing
the kernel.  But the virtio-blk protocol should probably be extended to
allow proper stacking of the disk's limits from the host.

This change fixes a crash that was reported when virtio-blk was used to
test linux-dm.git commit 604ea90641b4 ("dm thin: adjust max_sectors_kb
based on thinp blocksize") that will initially set max_sectors to
max_hw_sectors and then rounddown to the first power-of-2 factor of the
DM thin-pool's blocksize.  Basically that commit assumes drivers don't
suck when establishing max_hw_sectors so it acted like a canary in the
coal mine.

In the case of a DM thin-pool built ontop of virtio-blk data device
these are the insane limits that were established for the DM thin-pool:

  # cat /sys/block/dm-6/queue/max_sectors_kb
  1073741824
  # cat /sys/block/dm-6/queue/max_hw_sectors_kb
  2147483647

by stacking the virtio-blk device's limits:

  # cat /sys/block/vdb/queue/max_sectors_kb
  512
  # cat /sys/block/vdb/queue/max_hw_sectors_kb
  2147483647

Attempting to mkfs.xfs against a thin device from this thin-pool quickly
resulted in fs/direct-io.c:dio_send_cur_page()'s BUG_ON.

Signed-off-by: Mike Snitzer <snitzer@redhat.com>
Cc: stable@vger.kernel.org
---
 drivers/block/virtio_blk.c |    9 ++++++---
 1 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index c6a27d5..68efbdc 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -674,8 +674,11 @@ static int virtblk_probe(struct virtio_device *vdev)
 	/* No need to bounce any requests */
 	blk_queue_bounce_limit(q, BLK_BOUNCE_ANY);
 
-	/* No real sector limit. */
-	blk_queue_max_hw_sectors(q, -1U);
+	/*
+	 * Limited by disk's max_hw_sectors in host, but
+	 * without that info establish a sane default.
+	 */
+	blk_queue_max_hw_sectors(q, BLK_DEF_MAX_SECTORS);
 
 	/* Host can optionally specify maximum segment size and number of
 	 * segments. */
@@ -684,7 +687,7 @@ static int virtblk_probe(struct virtio_device *vdev)
 	if (!err)
 		blk_queue_max_segment_size(q, v);
 	else
-		blk_queue_max_segment_size(q, -1U);
+		blk_queue_max_segment_size(q, BLK_MAX_SEGMENT_SIZE);
 
 	/* Host can optionally specify the block size of the device */
 	err = virtio_cread_feature(vdev, VIRTIO_BLK_F_BLK_SIZE,
-- 
1.7.4.4

             reply	other threads:[~2014-11-20 19:00 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-20 19:00 Mike Snitzer [this message]
2014-11-20 20:30 ` [PATCH] virtio_blk: fix defaults for max_hw_sectors and max_segment_size Michael S. Tsirkin
2014-11-20 21:15   ` Mike Snitzer
2014-11-26  5:58     ` Rusty Russell
2014-11-26 14:10       ` Mike Snitzer
2014-11-21  1:59 ` Mike Snitzer
2014-11-21  2:11 ` [PATCH v2] " Mike Snitzer
2014-11-21  9:54 ` [PATCH] " Christoph Hellwig
2014-11-21  9:54   ` [Qemu-devel] " Christoph Hellwig
2014-11-21 15:49   ` Mike Snitzer
2014-11-21 15:49     ` [Qemu-devel] " Mike Snitzer
2014-11-26 19:48     ` Jens Axboe
2014-11-26 19:48       ` [Qemu-devel] " Jens Axboe
2014-11-26 20:51       ` Mike Snitzer
2014-11-26 20:51         ` [Qemu-devel] " Mike Snitzer
2014-11-26 20:54         ` Jens Axboe
2014-11-26 20:54           ` [Qemu-devel] " Jens Axboe
2014-11-26 21:51           ` Mike Snitzer
2014-11-26 21:51             ` [Qemu-devel] " Mike Snitzer
2014-11-26 21:51             ` Mike Snitzer
2014-11-26 21:53             ` Jens Axboe
2014-11-26 21:53               ` [Qemu-devel] " Jens Axboe
2014-11-26 23:00               ` Mike Snitzer
2014-11-26 23:00                 ` [Qemu-devel] " Mike Snitzer

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=20141120190058.GA31214@redhat.com \
    --to=snitzer@redhat.com \
    --cc=axboe@kernel.dk \
    --cc=dm-devel@redhat.com \
    --cc=hch@infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=mst@redhat.com \
    --cc=rusty@rustcorp.com.au \
    /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.