[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH RFC] xen/evtchn: Implement EVTCHNOP_send_imm as a companian to EVTCHNOP_send



On 17/07/2017 19:30, Stefano Stabellini wrote:
> On Fri, 14 Jul 2017, Jan Beulich wrote:
>>>>> On 13.07.17 at 09:50, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> --- a/xen/common/event_channel.c
>>> +++ b/xen/common/event_channel.c
>>> @@ -1098,6 +1098,10 @@ long do_event_channel_op(int cmd, 
>>> XEN_GUEST_HANDLE_PARAM(void) arg)
>>>          break;
>>>      }
>>>  
>>> +    case EVTCHNOP_send_imm:
>>> +        rc = evtchn_send(current->domain, (unsigned long)arg.p);
>> Two more things: For one this discards the upper half of the 64-bit
>> handle. I'd suggest you instead check it to be zero.
> +1, keeping in mind that arg will be 32-bit on ARM32 platforms and
> 64-bit on ARM64 platforms.
>
> Moreover, evtchn_send takes an unsigned int as argument, why are you
> casting arg.p to (unsigned long)?

Because arg.p is a pointer, and casting that to an unsigned int will
break on 64bit builds.  (IIRC, GCC tolerates casting a pointer to an
integer of suitable width, but not if a truncation would happen).

It probably wants to be:

uintptr_t port = (uintptr_t)arg.p;

if ( port > (evtchn_port_t)-1 )
    fail;

to be properly within the C spec.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.