From mboxrd@z Thu Jan  1 00:00:00 1970
From: Avi Kivity <avi@redhat.com>
Subject: Re: [PATCH RFC v2 6/6] KVM: introduce a new API for getting dirty
 bitmaps
Date: Fri, 23 Apr 2010 15:53:05 +0300
Message-ID: <4BD19831.5000405@redhat.com>
References: <20100420195349.dab60b1d.yoshikawa.takuya@oss.ntt.co.jp> <201004231427.30725.arnd@arndb.de> <4BD195B7.3070409@redhat.com> <201004231446.07880.arnd@arndb.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Cc: Alexander Graf <agraf@suse.de>,
	=?UTF-8?B?RmVybmFuZG8gTHVpcyBWw6F6cXVl?= =?UTF-8?B?eiBDYW8=?=
	<fernando@oss.ntt.co.jp>,
	Takuya Yoshikawa <yoshikawa.takuya@oss.ntt.co.jp>,
	mtosatti@redhat.com, kvm@vger.kernel.org, kvm-ia64@vger.kernel.org,
	kvm-ppc@vger.kernel.org
To: Arnd Bergmann <arnd@arndb.de>
Return-path: <kvm-owner@vger.kernel.org>
Received: from mx1.redhat.com ([209.132.183.28]:51685 "EHLO mx1.redhat.com"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1754565Ab0DWMxP (ORCPT <rfc822;kvm@vger.kernel.org>);
	Fri, 23 Apr 2010 08:53:15 -0400
In-Reply-To: <201004231446.07880.arnd@arndb.de>
Sender: kvm-owner@vger.kernel.org
List-ID: <kvm.vger.kernel.org>

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.