similar to: [PATCH] virtio_blk: fix panic in initialization error path

On Mon, Jan 09, 2017 at 11:44:12AM -0800, Omar Sandoval wrote: > From: Omar Sandoval <osandov at fb.com> > > If blk_mq_init_queue() returns an error, it gets assigned to > vblk->disk->queue. Then, when we call put_disk(), we end up calling > blk_put_queue() with the ERR_PTR, causing a bad dereference. Fix it by > only assigning to vblk->disk->queue on success.

From: Omar Sandoval <osandov at fb.com> put_chars() stuffs the buffer it gets into an sg, but that buffer may be on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it manifested as printks getting turned into NUL bytes). Signed-off-by: Omar Sandoval <osandov at fb.com> --- Patch based on v4.10-rc6. drivers/char/virtio_console.c | 12 ++++++++++-- 1 file changed, 10

From: Omar Sandoval <osandov at fb.com> put_chars() stuffs the buffer it gets into an sg, but that buffer may be on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it manifested as printks getting turned into NUL bytes). Signed-off-by: Omar Sandoval <osandov at fb.com> --- Patch based on v4.10-rc6. drivers/char/virtio_console.c | 12 ++++++++++-- 1 file changed, 10

On Wed, Feb 01, 2017 at 07:17:12PM +0530, Amit Shah wrote: > On (Wed) 01 Feb 2017 [00:02:27], Omar Sandoval wrote: > > From: Omar Sandoval <osandov at fb.com> > > > > put_chars() stuffs the buffer it gets into an sg, but that buffer may be > > on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it > > manifested as printks getting turned into NUL

On Wed, Feb 01, 2017 at 07:17:12PM +0530, Amit Shah wrote: > On (Wed) 01 Feb 2017 [00:02:27], Omar Sandoval wrote: > > From: Omar Sandoval <osandov at fb.com> > > > > put_chars() stuffs the buffer it gets into an sg, but that buffer may be > > on the stack. This breaks with CONFIG_VMAP_STACK=y (for me, it > > manifested as printks getting turned into NUL

Linux kernel only supports logical block sizes which are power of two, at least 512 bytes and no more that PAGE_SIZE. Check this instead of crashing later on. Note that there is no need to check physical block size since it is only a hint, and virtio-blk already only supports power of two values. Bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=1664619 Signed-off-by: Maxim Levitsky

Linux kernel only supports logical block sizes which are power of two, at least 512 bytes and no more that PAGE_SIZE. Check this instead of crashing later on. Note that there is no need to check physical block size since it is only a hint, and virtio-blk already only supports power of two values. Bugzilla link: https://bugzilla.redhat.com/show_bug.cgi?id=1664619 Signed-off-by: Maxim Levitsky

On Wed, 2020-07-15 at 06:06 -0400, Michael S. Tsirkin wrote: > On Wed, Jul 15, 2020 at 12:55:18PM +0300, Maxim Levitsky wrote: > > Linux kernel only supports logical block sizes which are power of > > two, > > at least 512 bytes and no more that PAGE_SIZE. > > > > Check this instead of crashing later on. > > > > Note that there is no need to check

On Wed, 2020-07-15 at 06:06 -0400, Michael S. Tsirkin wrote: > On Wed, Jul 15, 2020 at 12:55:18PM +0300, Maxim Levitsky wrote: > > Linux kernel only supports logical block sizes which are power of > > two, > > at least 512 bytes and no more that PAGE_SIZE. > > > > Check this instead of crashing later on. > > > > Note that there is no need to check

blk_mq_init_queue() returns ERR_PTR() on failure, not NULL. Signed-off-by: J?rg Billeter <j at bitron.ch> --- drivers/block/virtio_blk.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 7ef7c09..b1b5c75 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -638,8 +638,8 @@ static int

blk_mq_init_queue() returns ERR_PTR() on failure, not NULL. Signed-off-by: J?rg Billeter <j at bitron.ch> --- drivers/block/virtio_blk.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c index 7ef7c09..b1b5c75 100644 --- a/drivers/block/virtio_blk.c +++ b/drivers/block/virtio_blk.c @@ -638,8 +638,8 @@ static int

virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). Signed-off-by: Venkatesh Srinivas <venkateshs at google.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

virtio-blk set the default queue depth to 64 requests, which was insufficient for high-IOPS devices. Instead set the blk-queue depth to the device's virtqueue depth divided by two (each I/O requires at least two VQ entries). Signed-off-by: Venkatesh Srinivas <venkateshs at google.com> --- drivers/block/virtio_blk.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Most virtio setups have a fairly limited number of ring entries available. Enable S/G entry merging by default to fit into less of them. This restores the behavior at time of the virtio-blk blk-mq conversion, which was changed by commit "block: add queue flag for disabling SG merging" which made the behavior optional, but didn't update the existing drivers to keep their previous

Most virtio setups have a fairly limited number of ring entries available. Enable S/G entry merging by default to fit into less of them. This restores the behavior at time of the virtio-blk blk-mq conversion, which was changed by commit "block: add queue flag for disabling SG merging" which made the behavior optional, but didn't update the existing drivers to keep their previous

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and

Hi, These patches try to support multi virtual queues(multi-vq) in one virtio-blk device, and maps each virtual queue(vq) to blk-mq's hardware queue. With this approach, both scalability and performance on virtio-blk device can get improved. For verifying the improvement, I implements virtio-blk multi-vq over qemu's dataplane feature, and both handling host notification from each vq and