Re: [PATCH RFC v2 6/6] KVM: introduce a new API for getting dirty
Avi Kivity <[email protected]> Fri, 23 Apr 2010 12:53:05 +0000
| Newsgroups | org.kernel.vger.kvm-ia64,org.kernel.vger.kvm,org.kernel.vger.kvm-ppc |
|---|---|
| Message-ID | <[email protected]> |
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.