mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Marc Zyngier <marc.zyngier@arm.com>
To: Peng Hao <peng.hao2@zte.com.cn>,
	tglx@linutronix.de, jason@lakedaemon.net
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] irqchip: irq-gic-v4: return real error code
Date: Mon, 19 Mar 2018 08:30:49 +0000	[thread overview]
Message-ID: <ca0dabab-e141-8591-d0f8-d7343147574f@arm.com> (raw)
In-Reply-To: <1521459494-35746-1-git-send-email-peng.hao2@zte.com.cn>

On 19/03/18 11:38, Peng Hao wrote:
> __irq_domain_alloc_irqs will return some different error code, so we
> should return real error code in its_alloc_vcpu_irqs.

What do we gain by doing so? Do we end-up treating the error in a
different way? What does this actually improve? This is the kind of
information I'm looking for in a commit message. Not something that
describes the patch.

> 
> Signed-off-by: Peng Hao <peng.hao2@zte.com.cn>
> ---
>  drivers/irqchip/irq-gic-v4.c | 8 +++++---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/irqchip/irq-gic-v4.c b/drivers/irqchip/irq-gic-v4.c
> index dba9d67..ecd170d 100644
> --- a/drivers/irqchip/irq-gic-v4.c
> +++ b/drivers/irqchip/irq-gic-v4.c
> @@ -99,7 +99,7 @@
>  
>  int its_alloc_vcpu_irqs(struct its_vm *vm)
>  {
> -	int vpe_base_irq, i;
> +	int vpe_base_irq, i, ret = -ENOMEM;
>  
>  	vm->fwnode = irq_domain_alloc_named_id_fwnode("GICv4-vpe",
>  						      task_pid_nr(current));
> @@ -120,8 +120,10 @@ int its_alloc_vcpu_irqs(struct its_vm *vm)
>  	vpe_base_irq = __irq_domain_alloc_irqs(vm->domain, -1, vm->nr_vpes,
>  					       NUMA_NO_NODE, vm,
>  					       false, NULL);
> -	if (vpe_base_irq <= 0)
> +	if (vpe_base_irq <= 0) {
> +		ret = vpe_base_irq;
>  		goto err;

Given that a return value of zero denotes an actual error, we can now
pretend that everything went smoothly, except that none of the doorbells
are initialized. KVM will then try and request the interrupts, which
will fail (because 0 is not a valid interrupt number).

We thus went from a situation where the error was completely unambiguous
(failed to allocate a bunch of interrupts) to a situation where things
fail in a bizarre way because we cannot request the interrupts that we
just allocated (something that shouldn't really fail).

I cannot call this change a real improvement.

> +	}
>  
>  	for (i = 0; i < vm->nr_vpes; i++)
>  		vm->vpes[i]->irq = vpe_base_irq + i;
> @@ -134,7 +136,7 @@ int its_alloc_vcpu_irqs(struct its_vm *vm)
>  	if (vm->fwnode)
>  		irq_domain_free_fwnode(vm->fwnode);
>  
> -	return -ENOMEM;
> +	return ret;
>  }
>  
>  void its_free_vcpu_irqs(struct its_vm *vm)
> 

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

      reply	other threads:[~2018-03-19  8:30 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-03-19 11:38 Peng Hao
2018-03-19  8:30 ` Marc Zyngier [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ca0dabab-e141-8591-d0f8-d7343147574f@arm.com \
    --to=marc.zyngier@arm.com \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=peng.hao2@zte.com.cn \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®