similar to: [PATCH v2] virtio_blk: Fix a slient kernel panic

On 07/18/16 at 05:21P, Cornelia Huck wrote: > On Mon, 18 Jul 2016 22:01:29 +0800 > Minfei Huang <mnfhuang at gmail.com> wrote: > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > > index 42758b5..d920512 100644 > > --- a/drivers/block/virtio_blk.c > > +++ b/drivers/block/virtio_blk.c > > @@ -381,9 +381,9 @@ static int init_vq(struct

On 07/18/16 at 05:21P, Cornelia Huck wrote: > On Mon, 18 Jul 2016 22:01:29 +0800 > Minfei Huang <mnfhuang at gmail.com> wrote: > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > > index 42758b5..d920512 100644 > > --- a/drivers/block/virtio_blk.c > > +++ b/drivers/block/virtio_blk.c > > @@ -381,9 +381,9 @@ static int init_vq(struct

From: Minfei Huang <mnghuan at gmail.com> We do a lot of memory allocation in function init_vq, and don't handle the allocation failure properly. Then this function will return 0, although initialization fails due to lacking memory. At that moment, kernel will panic in guest machine, if virtio is used to drive disk. To fix this bug, we should take care of allocation failure, and return

From: Minfei Huang <mnghuan at gmail.com> We do a lot of memory allocation in function init_vq, and don't handle the allocation failure properly. Then this function will return 0, although initialization fails due to lacking memory. At that moment, kernel will panic in guest machine, if virtio is used to drive disk. To fix this bug, we should take care of allocation failure, and return

On Mon, 18 Jul 2016 22:01:29 +0800 Minfei Huang <mnfhuang at gmail.com> wrote: > We do a lot of memory allocation in function init_vq, and don't handle > the allocation failure properly. Then this function will return 0, > although initialization fails due to lacking memory. At that moment, > kernel will panic in guest machine, if virtio is used to drive disk. > > To

On Tue, 19 Jul 2016 00:18:32 +0800 Minfei Huang <mnfhuang at gmail.com> wrote: > On 07/18/16 at 05:21P, Cornelia Huck wrote: > > On Mon, 18 Jul 2016 22:01:29 +0800 > > Minfei Huang <mnfhuang at gmail.com> wrote: > > > diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c > > > index 42758b5..d920512 100644 > > > ---

The error number -ENOENT or 0 will be returned, if we can not allocate more memory in function init_vq. If host can support multiple virtual queues, and we fails to allocate necessary memory structures for vq, kernel may crash due to incorrect returning. To fix it, kernel will return correct value in init_vq. Signed-off-by: Minfei Huang <mnghuan at gmail.com> Signed-off-by: Minfei Huang

The error number -ENOENT or 0 will be returned, if we can not allocate more memory in function init_vq. If host can support multiple virtual queues, and we fails to allocate necessary memory structures for vq, kernel may crash due to incorrect returning. To fix it, kernel will return correct value in init_vq. Signed-off-by: Minfei Huang <mnghuan at gmail.com> Signed-off-by: Minfei Huang

We do a lot of memory allocation in function init_vq, and don't handle the allocation failure properly. Then this function will return 0, although initialization fails due to lacking memory. At that moment, kernel will panic in guest machine, if virtio is used to drive disk. To fix this bug, we should take care of allocation failure, and return correct value to let caller know what happen.

We do a lot of memory allocation in function init_vq, and don't handle the allocation failure properly. Then this function will return 0, although initialization fails due to lacking memory. At that moment, kernel will panic in guest machine, if virtio is used to drive disk. To fix this bug, we should take care of allocation failure, and return correct value to let caller know what happen.

On Thu, Jun 26, 2014 at 10:08:46AM +0800, Ming Lei wrote: > Firstly this patch supports more than one virtual queues for virtio-blk > device. > > Secondly this patch maps the virtual queue to blk-mq's hardware queue. > > With this approach, both scalability and performance can be improved. > > Signed-off-by: Ming Lei <ming.lei at canonical.com> > --- >

On Thu, Jun 26, 2014 at 10:08:46AM +0800, Ming Lei wrote: > Firstly this patch supports more than one virtual queues for virtio-blk > device. > > Secondly this patch maps the virtual queue to blk-mq's hardware queue. > > With this approach, both scalability and performance can be improved. > > Signed-off-by: Ming Lei <ming.lei at canonical.com> > --- >

On Mon, 27 Jun 2016 10:09:18 +0800 Minfei Huang <mnghuan at gmail.com> wrote: > The error number -ENOENT or 0 will be returned, if we can not allocate > more memory in function init_vq. If host can support multiple virtual > queues, and we fails to allocate necessary memory structures for vq, > kernel may crash due to incorrect returning. > > To fix it, kernel will return

On 3/13/19 1:33 AM, Cornelia Huck wrote: > On Tue, 12 Mar 2019 10:22:46 -0700 (PDT) > Dongli Zhang <dongli.zhang at oracle.com> wrote: > >> I observed that there is one msix vector for config and one shared vector >> for all queues in below qemu cmdline, when the num-queues for virtio-blk >> is more than the number of possible cpus: >> >> qemu:

On 3/13/19 1:33 AM, Cornelia Huck wrote: > On Tue, 12 Mar 2019 10:22:46 -0700 (PDT) > Dongli Zhang <dongli.zhang at oracle.com> wrote: > >> I observed that there is one msix vector for config and one shared vector >> for all queues in below qemu cmdline, when the num-queues for virtio-blk >> is more than the number of possible cpus: >> >> qemu:

I observed that there is one msix vector for config and one shared vector for all queues in below qemu cmdline, when the num-queues for virtio-blk is more than the number of possible cpus: qemu: "-smp 4" while "-device virtio-blk-pci,drive=drive-0,id=virtblk0,num-queues=6" # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 ... ... 24: 0

I observed that there is one msix vector for config and one shared vector for all queues in below qemu cmdline, when the num-queues for virtio-blk is more than the number of possible cpus: qemu: "-smp 4" while "-device virtio-blk-pci,drive=drive-0,id=virtblk0,num-queues=6" # cat /proc/interrupts CPU0 CPU1 CPU2 CPU3 ... ... 24: 0

On 13/06/2016 11:58, Bob Liu wrote: > A guest might be migrated to other hosts with different num_queues, the > blk-core should aware of that else the reference of &vblk->vqs[qid] may be wrong. > > Signed-off-by: Bob Liu <bob.liu at oracle.com> > --- > drivers/block/virtio_blk.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git

On 13/06/2016 11:58, Bob Liu wrote: > A guest might be migrated to other hosts with different num_queues, the > blk-core should aware of that else the reference of &vblk->vqs[qid] may be wrong. > > Signed-off-by: Bob Liu <bob.liu at oracle.com> > --- > drivers/block/virtio_blk.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git

On 3/13/19 5:39 PM, Cornelia Huck wrote: > On Wed, 13 Mar 2019 11:26:04 +0800 > Dongli Zhang <dongli.zhang at oracle.com> wrote: > >> On 3/13/19 1:33 AM, Cornelia Huck wrote: >>> On Tue, 12 Mar 2019 10:22:46 -0700 (PDT) >>> Dongli Zhang <dongli.zhang at oracle.com> wrote: >>> >>>> I observed that there is one msix vector for