Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1442375 > unrolled thread

Re: [PATCH] virtio: Return correct errno for function init_vq's failure

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH] virtio: Return correct errno for function init_vq's  failure Minfei Huang <mnghuan@gmail.com> - 2016-07-13 14:00 +0200
    Re: [PATCH] virtio: Return correct errno for function init_vq's  failure Cornelia Huck <cornelia.huck@de.ibm.com> - 2016-07-13 14:10 +0200

#1442375 — Re: [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@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 correct value in init_vq.
> The error handling in this function looks horrible.
> 
> When mq was introduced, init_vq started mixing up several things:
> - The mq feature is not available - which is not an error, and
> therefore should not have any influence on the return code.
> - One of the several memory allocations failed - only ->vqs gets
> special treatment, however.
> - The ->find_vqs callback failed.

Yep. And without this patch, it is silent for boot failure. I think it
makes sense to let user notify about this failure.

> 
> Your patch fixes the code, but it is still very convoluted due to the
> temporary arrays.
> 
> May it be worthwile to introduce a helper for setting up the virtqueues
> where all virtqueues are essentially the same and just get a
> consecutive number? Michael?
> 

Hmm, How about refactor this function to make it more readable, since we
do a lot of work in it.

I will post an update to refactor this function.

Thanks
Minfei

[toc] | [next] | [standalone]

#1442377

On Wed, 13 Jul 2016 19:54:00 +0800
Minfei Huang <mnghuan@gmail.com> wrote:

> On 07/06/16 at 11:18P, Cornelia Huck wrote:
> > On Mon, 27 Jun 2016 10:09:18 +0800
> > Minfei Huang <mnghuan@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 correct value in init_vq.
> > The error handling in this function looks horrible.
> > 
> > When mq was introduced, init_vq started mixing up several things:
> > - The mq feature is not available - which is not an error, and
> > therefore should not have any influence on the return code.
> > - One of the several memory allocations failed - only ->vqs gets
> > special treatment, however.
> > - The ->find_vqs callback failed.
> 
> Yep. And without this patch, it is silent for boot failure. I think it
> makes sense to let user notify about this failure.

Agreed.

> 
> > 
> > Your patch fixes the code, but it is still very convoluted due to the
> > temporary arrays.
> > 
> > May it be worthwile to introduce a helper for setting up the virtqueues
> > where all virtqueues are essentially the same and just get a
> > consecutive number? Michael?
> > 
> 
> Hmm, How about refactor this function to make it more readable, since we
> do a lot of work in it.
> 
> I will post an update to refactor this function.

Anything to make this more readable probably helps :)

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web