Re: [PATCH 2 of 5] add can_dma/post_dma for direct IO

Anthony Liguori
2008-12-13T21:12:02Z

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