[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9b66ef8f-c21b-4ad8-9f36-51ce653be661@suse.com>
Date: Wed, 27 Aug 2025 17:16:00 +0200
From: Jürgen Groß <jgross@...e.com>
To: Jason Andryuk <jason.andryuk@....com>, Jan Beulich <jbeulich@...e.com>
Cc: xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
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.25 17:03, Jason Andryuk wrote:
> On 2025-08-26 03:22, Jan Beulich wrote:
>> 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 ...
>
> I'll state that here...
>
>>
>>> 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@.
>
> and add these.
>
>>
>>> --- 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)?
>
> Sounds good.
>
>> Either way:
>> Reviewed-by: Jan Beulich <jbeulich@...e.com>
With the changes you promised to do:
Reviewed-by: Juergen Gross <jgross@...e.com>
Juergen
Download attachment "OpenPGP_0xB0DE9DD628BF132F.asc" of type "application/pgp-keys" (3684 bytes)
Download attachment "OpenPGP_signature.asc" of type "application/pgp-signature" (496 bytes)
Powered by blists - more mailing lists