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

Re: [Xen-devel] [PATCH 1/3] x86/mem_access: Make the mem_access ops generic



>>> On 11.04.14 at 11:53, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 11/04/14 10:48, Jan Beulich wrote:
>>>>> On 11.04.14 at 11:35, <andrew.cooper3@xxxxxxxxxx> wrote:
>>> On 11/04/14 04:49, Aravindh Puthiyaparambil wrote:
>>>> --- a/xen/arch/x86/mm/mem_access.c
>>>> +++ b/xen/arch/x86/mm/mem_access.c
>>>> @@ -21,31 +21,98 @@
>>>>   */
>>>>  
>>>>  
>>>> +#include <xen/sched.h>
>>>> +#include <xen/guest_access.h>
>>>> +#include <xen/hypercall.h>
>>>>  #include <asm/p2m.h>
>>>>  #include <asm/mem_event.h>
>>>> +#include <xsm/xsm.h>
>>>>  
>>>>  
>>>> -int mem_access_memop(struct domain *d, xen_mem_event_op_t *meo)
>>>> +#define ACCESS_op_mask  0xff
>>>> +
>>>> +int mem_access_memop(XEN_GUEST_HANDLE_PARAM(void) arg, unsigned long 
>>> start_iter)
>>>>  {
>>>> -    int rc;
>>>> +    long rc;
>>> int function and long rc? The function wants promoting to long.
>> No, what makes it out of the function fits in an "int", 
> 
> Why does that matter?  It is a recipe for accidental truncation with
> future changes (and certainly not the first example in Xen).
> 
> All hypercall handlers should be returning longs, and leaving it to the
> compat layer to apply correct truncation if needed.

For top level hypercall handlers I agree, but for helper functions
like this one I don't.

Jan


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


 


Rackspace

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