From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO Date: Sat, 13 Dec 2008 15:11:57 -0600 Message-ID: <4944251D.8080109@codemonkey.ws> References: <4942B841.6010900@codemonkey.ws> <20081213143944.GD30537@random.random> <4943E6F9.1050001@codemonkey.ws> <20081213165306.GE30537@random.random> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Gerd Hoffmann , qemu-devel@nongnu.org, kvm@vger.kernel.org, avi@redhat.com, chrisw@redhat.com To: Andrea Arcangeli Return-path: Received: from yx-out-2324.google.com ([74.125.44.29]:46209 "EHLO yx-out-2324.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751655AbYLMVMC (ORCPT ); Sat, 13 Dec 2008 16:12:02 -0500 Received: by yx-out-2324.google.com with SMTP id 8so896372yxm.1 for ; Sat, 13 Dec 2008 13:12:01 -0800 (PST) In-Reply-To: <20081213165306.GE30537@random.random> Sender: kvm-owner@vger.kernel.org List-ID: Andrea Arcangeli wrote: > On Sat, Dec 13, 2008 at 10:46:49AM -0600, Anthony Liguori wrote: > > Not sure why you think I'm suggesting you to use size_t. I'm just > trying to tell you that if you insist in this > 64bit-guest-on-32bit-host-is-dead-and-obsolete-to-support (i.e. if you > pass a ram_addr_t size to cpu_physical_memory_map) you've at least to > return ram_addr_t too). 'void *' is like size_t so the above API > getting ram_addr_t length and returning 'void *', can't possibly be > sane. > If you take a size_t, then all callers have to validate that the size they're passing in (which may originate from the guest), is not going to cause an overflow. You will naturally validate this in the map() function because you cannot map something that is greater than can fit in a void *. All callers have to handle the case where return is NULL from map() which means that you can fold this error checking into map() without the callers having to even think of it. Regards, Anthony Liguori