linux-kernel - Re: [PATCH v2 1/3] xen/events: Cleanup find

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <cdbd3849-c366-4d25-bf72-23587d79ab6e@amd.com>
Date: Tue, 26 Aug 2025 11:03:12 -0400
From: Jason Andryuk <jason.andryuk@....com>
To: Jan Beulich <jbeulich@...e.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 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>

Thanks.

> 
>>   	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.

Agreed.

Thanks,
Jason