Re: [PATCH RFC v2 6/6] KVM: introduce a new API for getting dirty bitmaps

Avi Kivity
2010-04-23T12:53:15Z

On 04/23/2010 03:46 PM, Arnd Bergmann wrote:
> On Friday 23 April 2010, Avi Kivity wrote:
>
>> On 04/23/2010 03:27 PM, Arnd Bergmann wrote:
>>
>>>
>>>> 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.
>>>
>>>
>> Ah, much more convenient than compat_ioctl. I assume it part of the
>> ABI, not a gccism?
>>
> I don't think it's part of the ABI, but it's required to guarantee
> that code like this works:
>
> int compare_pointer(void *a, void *b)
> {
> unsigned long ai = (unsigned long)a, bi = (unsigned long)b;
>
> return ai == bi; /* true if a and b point to the same object */
> }
>
> We certainly rely on this already.
>

Ah so the 31st bit is optional as far as userspace is concerned? What
does it mean? (just curious)

What happens on the opposite conversion? is it restored?

What about

int compare_pointer(void *a, void *b)
{
unsigned long ai = (unsigned long)a;
void *aia = (void *)ai;

return a == b; /* true if a and b point to the same object */
}

Does gcc mask the big in pointer comparisons as well?

--
Do not meddle in the internals of kernels, for they are subtle and quick to panic.