On Friday 23 April 2010, Avi Kivity wrote:
> On 04/23/2010 01:20 PM, Alexander Graf wrote:
> >
> >> I would say the reason is that if we did not convert the user-space pointer to
> >> a "void *" kvm_get_dirty_log() would end up copying the dirty log to
> >>
> >> (log->dirty_bitmap<< 32) | 0x00000000
> >>
> > Well yes, that was the problem. If we always set the __u64 value to the pointer we're safe though.
> >
> > union {
> > void *p;
> > __u64 q;
> > }
> >
> > void x(void *r)
> > {
> > // breaks:
> > p = r;
> >
> > // works:
> > q = (ulong)r;
> > }
> >
>
> In that case it's better to avoid p altogether, since users will
> naturally assign to the pointer.
Right.
> Using a 64-bit integer avoids the problem (though perhaps not sufficient
> for s390, Arnd?)
When there is only a __u64 for the address, it will work on s390 as well,
gcc is smart enough to clear the upper bit on a cast from long to pointer.
The simple rule is to never put any 'long' or pointer into data structures
that you pass to an ioctl, and to add padding to multiples of 64 bit to
align the data structure for the x86 alignment problem.
Arnd
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
