Displaying 20 results from an estimated 4000 matches similar to: "[PATCH] virtio: Return correct errno for function init_vq's failure"
2016 Jul 18
2
[PATCH v2] virtio_blk: Fix a slient kernel panic
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.
2016 Jul 18
2
[PATCH v2] virtio_blk: Fix a slient kernel panic
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.
2016 Jul 06
0
[PATCH] virtio: Return correct errno for function init_vq's failure
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
2016 Jul 19
4
[PATCH v3] virtio_blk: Fix a slient kernel panic
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
2016 Jul 19
4
[PATCH v3] virtio_blk: Fix a slient kernel panic
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
2016 Jul 13
1
[PATCH] virtio: Return correct errno for function init_vq's failure
On 07/06/16 at 11:18P, Cornelia Huck wrote:
> 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
2016 Jul 13
1
[PATCH] virtio: Return correct errno for function init_vq's failure
On 07/06/16 at 11:18P, Cornelia Huck wrote:
> 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
2016 Jul 18
2
[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
2016 Jul 18
2
[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
2016 Jul 18
0
[PATCH v2] virtio_blk: Fix a slient kernel panic
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
2016 Aug 09
0
[PATCH RESEND] virtio_blk: Fix a slient kernel panic
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.
2016 Aug 09
0
[PATCH RESEND] virtio_blk: Fix a slient kernel panic
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.
2014 Jun 26
1
[PATCH v2 2/2] block: virtio-blk: support multi virt queues per virtio-blk device
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>
> ---
>
2014 Jun 26
1
[PATCH v2 2/2] block: virtio-blk: support multi virt queues per virtio-blk device
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>
> ---
>
2016 Jul 18
0
[PATCH v2] virtio_blk: Fix a slient kernel panic
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
> > > ---
2019 Mar 12
4
virtio-blk: should num_vqs be limited by num_possible_cpus()?
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
2019 Mar 12
4
virtio-blk: should num_vqs be limited by num_possible_cpus()?
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
2019 Mar 13
2
virtio-blk: should num_vqs be limited by num_possible_cpus()?
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:
2019 Mar 13
2
virtio-blk: should num_vqs be limited by num_possible_cpus()?
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:
2019 Mar 14
4
virtio-blk: should num_vqs be limited by num_possible_cpus()?
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