Re: [Xen-devel] [PATCH 4/5] xen: Enforce casting for guest_handle_cast

[Tim Deegan <tim@xxxxxxx>]

At 15:08 +0100 on 14 Jun (1339686495), Jean Guyader wrote:
> On 31/05 04:47, Jan Beulich wrote:
> > >>> On 31.05.12 at 17:07, Jean Guyader <jean.guyader@xxxxxxxxxx> wrote:
> > >--- a/xen/include/asm-x86/guest_access.h
> > >+++ b/xen/include/asm-x86/guest_access.h
> > >@@ -47,7 +47,7 @@
> > > 
> > > /* Cast a guest handle to the specified type of handle. */
> > > #define guest_handle_cast(hnd, type) ({         \
> > >-    type *_x = (hnd).p;                         \
> > >+    type *_x = (type *)(hnd).p;                 \
> > 
> > 
> > You would have to explain how this is safe: Without the cast, we
> > get compiler warnings (and hence build failures due to -Werror)
> > if "type *" and typeof((hnd).p) are incompatible. Adding an
> > explicit cast removes that intentional check.
> > 
> 
> I can't realy explain how this is safe because I agree it make
> this function less safe.
> 
> Maybe I should put here the reason that led me to do something
> like that. Here is what I'm trying to do:
> 
>         XEN_GUEST_HANDLE (uint8_t) slop_hnd =
>                 guest_handle_cast (pfn_list_hnd, uint8_t);
>         guest_handle_add_offset (slop_hnd, sizeof (v4v_pfn_list_t));
>         pfn_hnd = guest_handle_cast (slop_hnd, v4v_pfn_t);
> 
> I need to cast to uint8_t first to get the add_offset to behave
> correctly. Maybe what I need would need a new macro that would
> do those two operations.
> 
> What would be the proper way to doing something like this?

You could avoid it altogether by dropping struct v4v_ring_data, and
passing a v4v_pfn_t array directly with the 'npage' as a separate
hypercall argument.  AFAICS struct v4v_ring_data has no other useful
fields.

Tim.

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