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

[Avi Kivity <avi@redhat.com>]

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.