[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <de9005bf-c858-4e7e-bea8-33e5ea2424fc@suse.com>
Date: Tue, 26 Aug 2025 09:22:10 +0200
From: Jan Beulich <jbeulich@...e.com>
To: Jason Andryuk <jason.andryuk@....com>
Cc: xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
Juergen Gross <jgross@...e.com>, Stefano Stabellini
<sstabellini@...nel.org>,
Oleksandr Tyshchenko <oleksandr_tyshchenko@...m.com>
Subject: Re: [PATCH v2 1/3] xen/events: Cleanup find_virq() return codes
On 26.08.2025 02:55, Jason Andryuk wrote:
> rc is overwritten by the evtchn_status hypercall in each iteration, so
> the return value will be whatever the last iteration is.
Which may even be a false "success". Especially for that it feels like ...
> Change to an
> explicit -ENOENT for an un-found virq and return 0 on a successful
> match.
>
> Signed-off-by: Jason Andryuk <jason.andryuk@....com>
... this also wants a Fixes: tag and perhaps a Cc: to stable@.
> --- a/drivers/xen/events/events_base.c
> +++ b/drivers/xen/events/events_base.c
> @@ -1318,7 +1318,7 @@ static int find_virq(unsigned int virq, unsigned int cpu, evtchn_port_t *evtchn)
> {
> struct evtchn_status status;
> evtchn_port_t port;
> - int rc = -ENOENT;
> + int rc;
Maybe best to also move this into the more narrow scope (loop body)?
Either way:
Reviewed-by: Jan Beulich <jbeulich@...e.com>
> memset(&status, 0, sizeof(status));
Having this outside of the loop is a little odd, too: It makes assumptions
on the behavior of the hypervisor (like not altering the structure upon
error). Yet likely not something to deal with right here.
Jan
Powered by blists - more mailing lists