* [PATCH v2] virtio_blk: Fix a slient kernel panic
@ 2016-07-18 14:01 Minfei Huang
2016-07-18 15:21 ` Cornelia Huck
0 siblings, 1 reply; 5+ messages in thread
From: Minfei Huang @ 2016-07-18 14:01 UTC (permalink / raw)
To: mst, cornelia.huck
Cc: virtualization, linux-kernel, fanc.fnst, Minfei Huang, 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.
Tested-by: Chao Fan <fanc.fnst@cn.fujitsu.com>
Signed-off-by: Minfei Huang <minfei.hmf@alibaba-inc.com>
Signed-off-by: Minfei Huang <mnghuan@gmail.com>
---
v1:
- Refactor the patch to make code more readable
---
drivers/block/virtio_blk.c | 32 +++++++++++---------------------
1 file changed, 11 insertions(+), 21 deletions(-)
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 virtio_blk *vblk)
{
int err = 0;
int i;
- vq_callback_t **callbacks;
- const char **names;
- struct virtqueue **vqs;
+ vq_callback_t **callbacks = NULL;
+ const char **names = NULL;
+ struct virtqueue **vqs = NULL;
unsigned short num_vqs;
struct virtio_device *vdev = vblk->vdev;
@@ -394,22 +394,16 @@ static int init_vq(struct virtio_blk *vblk)
num_vqs = 1;
vblk->vqs = kmalloc(sizeof(*vblk->vqs) * num_vqs, GFP_KERNEL);
- if (!vblk->vqs) {
- err = -ENOMEM;
- goto out;
- }
+ if (!vblk->vqs)
+ return -ENOMEM;
names = kmalloc(sizeof(*names) * num_vqs, GFP_KERNEL);
- if (!names)
- goto err_names;
-
callbacks = kmalloc(sizeof(*callbacks) * num_vqs, GFP_KERNEL);
- if (!callbacks)
- goto err_callbacks;
-
vqs = kmalloc(sizeof(*vqs) * num_vqs, GFP_KERNEL);
- if (!vqs)
- goto err_vqs;
+ if (!names || !callbacks || !vqs) {
+ err = -ENOMEM;
+ goto out;
+ }
for (i = 0; i < num_vqs; i++) {
callbacks[i] = virtblk_done;
@@ -420,7 +414,7 @@ static int init_vq(struct virtio_blk *vblk)
/* Discover virtqueues and write information to configuration. */
err = vdev->config->find_vqs(vdev, num_vqs, vqs, callbacks, names);
if (err)
- goto err_find_vqs;
+ goto out;
for (i = 0; i < num_vqs; i++) {
spin_lock_init(&vblk->vqs[i].lock);
@@ -428,16 +422,12 @@ static int init_vq(struct virtio_blk *vblk)
}
vblk->num_vqs = num_vqs;
- err_find_vqs:
+out:
kfree(vqs);
- err_vqs:
kfree(callbacks);
- err_callbacks:
kfree(names);
- err_names:
if (err)
kfree(vblk->vqs);
- out:
return err;
}
--
2.7.4 (Apple Git-66)
^ permalink raw reply related [flat|nested] 5+ messages in thread* Re: [PATCH v2] virtio_blk: Fix a slient kernel panic
2016-07-18 14:01 [PATCH v2] virtio_blk: Fix a slient kernel panic Minfei Huang
@ 2016-07-18 15:21 ` Cornelia Huck
2016-07-18 16:18 ` Minfei Huang
0 siblings, 1 reply; 5+ messages in thread
From: Cornelia Huck @ 2016-07-18 15:21 UTC (permalink / raw)
To: Minfei Huang
Cc: mst, virtualization, linux-kernel, fanc.fnst, Minfei Huang, Minfei Huang
On Mon, 18 Jul 2016 22:01:29 +0800
Minfei Huang <mnfhuang@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 fix this bug, we should take care of allocation failure, and return
> correct value to let caller know what happen.
>
> Tested-by: Chao Fan <fanc.fnst@cn.fujitsu.com>
> Signed-off-by: Minfei Huang <minfei.hmf@alibaba-inc.com>
> Signed-off-by: Minfei Huang <mnghuan@gmail.com>
> ---
> v1:
> - Refactor the patch to make code more readable
> ---
> drivers/block/virtio_blk.c | 32 +++++++++++---------------------
> 1 file changed, 11 insertions(+), 21 deletions(-)
>
> 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 virtio_blk *vblk)
> {
> int err = 0;
> int i;
> - vq_callback_t **callbacks;
> - const char **names;
> - struct virtqueue **vqs;
> + vq_callback_t **callbacks = NULL;
> + const char **names = NULL;
> + struct virtqueue **vqs = NULL;
If you init the variables to NULL anyway...
> unsigned short num_vqs;
> struct virtio_device *vdev = vblk->vdev;
>
> @@ -394,22 +394,16 @@ static int init_vq(struct virtio_blk *vblk)
> num_vqs = 1;
>
...just do
err = -ENOMEM;
here and...
> vblk->vqs = kmalloc(sizeof(*vblk->vqs) * num_vqs, GFP_KERNEL);
> - if (!vblk->vqs) {
> - err = -ENOMEM;
> - goto out;
> - }
> + if (!vblk->vqs)
> + return -ENOMEM;
>
> names = kmalloc(sizeof(*names) * num_vqs, GFP_KERNEL);
> - if (!names)
> - goto err_names;
> -
> callbacks = kmalloc(sizeof(*callbacks) * num_vqs, GFP_KERNEL);
> - if (!callbacks)
> - goto err_callbacks;
> -
> vqs = kmalloc(sizeof(*vqs) * num_vqs, GFP_KERNEL);
> - if (!vqs)
> - goto err_vqs;
> + if (!names || !callbacks || !vqs) {
> + err = -ENOMEM;
> + goto out;
> + }
...you could use the
foo = kmalloc(...);
if (!foo)
goto out;
sequence in any case. This avoids trying again and again if e.g. the
names allocation already failed.
Alternatively, you should be fine if you don't init the variables to
NULL: The code is now either taking an early exit or setting all of the
variables anyway.
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH v2] virtio_blk: Fix a slient kernel panic
2016-07-18 15:21 ` Cornelia Huck
@ 2016-07-18 16:18 ` Minfei Huang
2016-07-18 16:25 ` Cornelia Huck
0 siblings, 1 reply; 5+ messages in thread
From: Minfei Huang @ 2016-07-18 16:18 UTC (permalink / raw)
To: Cornelia Huck
Cc: Minfei Huang, mst, virtualization, linux-kernel, fanc.fnst, Minfei Huang
On 07/18/16 at 05:21P, Cornelia Huck wrote:
> On Mon, 18 Jul 2016 22:01:29 +0800
> Minfei Huang <mnfhuang@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 virtio_blk *vblk)
> > {
> > int err = 0;
> > int i;
> > - vq_callback_t **callbacks;
> > - const char **names;
> > - struct virtqueue **vqs;
> > + vq_callback_t **callbacks = NULL;
> > + const char **names = NULL;
> > + struct virtqueue **vqs = NULL;
>
> If you init the variables to NULL anyway...
Hi, Cornelia.
Thanks for reviewing this patch.
Seems there is no need to init these variables to NULL. I will remove
them laster.
>
> > unsigned short num_vqs;
> > struct virtio_device *vdev = vblk->vdev;
> >
> > @@ -394,22 +394,16 @@ static int init_vq(struct virtio_blk *vblk)
> > num_vqs = 1;
> >
>
> ...just do
>
> err = -ENOMEM;
>
> here and...
>
> > vblk->vqs = kmalloc(sizeof(*vblk->vqs) * num_vqs, GFP_KERNEL);
> > - if (!vblk->vqs) {
> > - err = -ENOMEM;
> > - goto out;
> > - }
> > + if (!vblk->vqs)
> > + return -ENOMEM;
> >
> > names = kmalloc(sizeof(*names) * num_vqs, GFP_KERNEL);
> > - if (!names)
> > - goto err_names;
> > -
> > callbacks = kmalloc(sizeof(*callbacks) * num_vqs, GFP_KERNEL);
> > - if (!callbacks)
> > - goto err_callbacks;
> > -
> > vqs = kmalloc(sizeof(*vqs) * num_vqs, GFP_KERNEL);
> > - if (!vqs)
> > - goto err_vqs;
> > + if (!names || !callbacks || !vqs) {
> > + err = -ENOMEM;
> > + goto out;
> > + }
>
> ...you could use the
>
> foo = kmalloc(...);
> if (!foo)
> goto out;
>
> sequence in any case. This avoids trying again and again if e.g. the
> names allocation already failed.
For this implementation, I have referred others which calls
vdev->config->find_vqs as well. Yes, this continues trying to allocate
memory, although memory allocation failed before.
>
> Alternatively, you should be fine if you don't init the variables to
> NULL: The code is now either taking an early exit or setting all of the
> variables anyway.
>
It's a big change if we refactor the helper ->find_vqs, since other
devices also call it.
Thanks
Minfei
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH v2] virtio_blk: Fix a slient kernel panic
2016-07-18 16:18 ` Minfei Huang
@ 2016-07-18 16:25 ` Cornelia Huck
2016-07-19 0:37 ` Minfei Huang
0 siblings, 1 reply; 5+ messages in thread
From: Cornelia Huck @ 2016-07-18 16:25 UTC (permalink / raw)
To: Minfei Huang; +Cc: mst, virtualization, linux-kernel, fanc.fnst, Minfei Huang
On Tue, 19 Jul 2016 00:18:32 +0800
Minfei Huang <mnfhuang@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@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 virtio_blk *vblk)
> > > {
> > > int err = 0;
> > > int i;
> > > - vq_callback_t **callbacks;
> > > - const char **names;
> > > - struct virtqueue **vqs;
> > > + vq_callback_t **callbacks = NULL;
> > > + const char **names = NULL;
> > > + struct virtqueue **vqs = NULL;
> >
> > If you init the variables to NULL anyway...
>
> Hi, Cornelia.
>
> Thanks for reviewing this patch.
>
> Seems there is no need to init these variables to NULL. I will remove
> them laster.
Fine with me.
>
> >
> > > unsigned short num_vqs;
> > > struct virtio_device *vdev = vblk->vdev;
> > >
> > > @@ -394,22 +394,16 @@ static int init_vq(struct virtio_blk *vblk)
> > > num_vqs = 1;
> > >
> >
> > ...just do
> >
> > err = -ENOMEM;
> >
> > here and...
> >
> > > vblk->vqs = kmalloc(sizeof(*vblk->vqs) * num_vqs, GFP_KERNEL);
> > > - if (!vblk->vqs) {
> > > - err = -ENOMEM;
> > > - goto out;
> > > - }
> > > + if (!vblk->vqs)
> > > + return -ENOMEM;
> > >
> > > names = kmalloc(sizeof(*names) * num_vqs, GFP_KERNEL);
> > > - if (!names)
> > > - goto err_names;
> > > -
> > > callbacks = kmalloc(sizeof(*callbacks) * num_vqs, GFP_KERNEL);
> > > - if (!callbacks)
> > > - goto err_callbacks;
> > > -
> > > vqs = kmalloc(sizeof(*vqs) * num_vqs, GFP_KERNEL);
> > > - if (!vqs)
> > > - goto err_vqs;
> > > + if (!names || !callbacks || !vqs) {
> > > + err = -ENOMEM;
> > > + goto out;
> > > + }
> >
> > ...you could use the
> >
> > foo = kmalloc(...);
> > if (!foo)
> > goto out;
> >
> > sequence in any case. This avoids trying again and again if e.g. the
> > names allocation already failed.
>
> For this implementation, I have referred others which calls
> vdev->config->find_vqs as well. Yes, this continues trying to allocate
> memory, although memory allocation failed before.
It might not be the best idea, though; although it should hopefully be
a not-so-common occurrence.
>
> >
> > Alternatively, you should be fine if you don't init the variables to
> > NULL: The code is now either taking an early exit or setting all of the
> > variables anyway.
> >
>
> It's a big change if we refactor the helper ->find_vqs, since other
> devices also call it.
Actually, I was referring to not initializing the variables to NULL in
this function and keeping the rest of your changes: IOW, just what you
suggested above :)
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [PATCH v2] virtio_blk: Fix a slient kernel panic
2016-07-18 16:25 ` Cornelia Huck
@ 2016-07-19 0:37 ` Minfei Huang
0 siblings, 0 replies; 5+ messages in thread
From: Minfei Huang @ 2016-07-19 0:37 UTC (permalink / raw)
To: Cornelia Huck
Cc: Minfei Huang, mst, virtualization, linux-kernel, fanc.fnst, Minfei Huang
On 07/18/16 at 06:25P, Cornelia Huck wrote:
> On Tue, 19 Jul 2016 00:18:32 +0800
> Minfei Huang <mnfhuang@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@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 virtio_blk *vblk)
> > > > {
> > > > int err = 0;
> > > > int i;
> > > > - vq_callback_t **callbacks;
> > > > - const char **names;
> > > > - struct virtqueue **vqs;
> > > > + vq_callback_t **callbacks = NULL;
> > > > + const char **names = NULL;
> > > > + struct virtqueue **vqs = NULL;
> > >
> > > If you init the variables to NULL anyway...
> >
> > Hi, Cornelia.
> >
> > Thanks for reviewing this patch.
> >
> > Seems there is no need to init these variables to NULL. I will remove
> > them laster.
>
> Fine with me.
>
> >
> > >
> > > > unsigned short num_vqs;
> > > > struct virtio_device *vdev = vblk->vdev;
> > > >
> > > > @@ -394,22 +394,16 @@ static int init_vq(struct virtio_blk *vblk)
> > > > num_vqs = 1;
> > > >
> > >
> > > ...just do
> > >
> > > err = -ENOMEM;
> > >
> > > here and...
> > >
> > > > vblk->vqs = kmalloc(sizeof(*vblk->vqs) * num_vqs, GFP_KERNEL);
> > > > - if (!vblk->vqs) {
> > > > - err = -ENOMEM;
> > > > - goto out;
> > > > - }
> > > > + if (!vblk->vqs)
> > > > + return -ENOMEM;
> > > >
> > > > names = kmalloc(sizeof(*names) * num_vqs, GFP_KERNEL);
> > > > - if (!names)
> > > > - goto err_names;
> > > > -
> > > > callbacks = kmalloc(sizeof(*callbacks) * num_vqs, GFP_KERNEL);
> > > > - if (!callbacks)
> > > > - goto err_callbacks;
> > > > -
> > > > vqs = kmalloc(sizeof(*vqs) * num_vqs, GFP_KERNEL);
> > > > - if (!vqs)
> > > > - goto err_vqs;
> > > > + if (!names || !callbacks || !vqs) {
> > > > + err = -ENOMEM;
> > > > + goto out;
> > > > + }
> > >
> > > ...you could use the
> > >
> > > foo = kmalloc(...);
> > > if (!foo)
> > > goto out;
> > >
> > > sequence in any case. This avoids trying again and again if e.g. the
> > > names allocation already failed.
> >
> > For this implementation, I have referred others which calls
> > vdev->config->find_vqs as well. Yes, this continues trying to allocate
> > memory, although memory allocation failed before.
>
> It might not be the best idea, though; although it should hopefully be
> a not-so-common occurrence.
Yep, for that memont, there is enough memory to be allocated.
>
> >
> > >
> > > Alternatively, you should be fine if you don't init the variables to
> > > NULL: The code is now either taking an early exit or setting all of the
> > > variables anyway.
> > >
> >
> > It's a big change if we refactor the helper ->find_vqs, since other
> > devices also call it.
>
> Actually, I was referring to not initializing the variables to NULL in
> this function and keeping the rest of your changes: IOW, just what you
> suggested above :)
Ok. I will repost an update to fix it.
Thanks
Minfei
>
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-07-19 0:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-07-18 14:01 [PATCH v2] virtio_blk: Fix a slient kernel panic Minfei Huang
2016-07-18 15:21 ` Cornelia Huck
2016-07-18 16:18 ` Minfei Huang
2016-07-18 16:25 ` Cornelia Huck
2016-07-19 0:37 ` Minfei Huang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).