From mboxrd@z Thu Jan 1 00:00:00 1970 From: Avi Kivity Date: Fri, 23 Apr 2010 12:53:05 +0000 Subject: Re: [PATCH RFC v2 6/6] KVM: introduce a new API for getting dirty Message-Id: <4BD19831.5000405@redhat.com> List-Id: References: <20100420200353.2d2a6dec.yoshikawa.takuya@oss.ntt.co.jp> In-Reply-To: <20100420200353.2d2a6dec.yoshikawa.takuya@oss.ntt.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: kvm-ia64@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.