[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v6 07/24] arm/x86/vmap: Add vmalloc_type and vm_init_type

>>> On 08.04.16 at 16:22, <andrew.cooper3@xxxxxxxxxx> wrote:
> On 07/04/16 04:49, Konrad Rzeszutek Wilk wrote:
>> +void vm_free_type(const void *, enum vmap_type);
>> +void vunmap_type(const void *, enum vmap_type);
>> +void *vmalloc_type(size_t size, enum vmap_type type, mfn_t **mfn_array);
>> +void vm_init_type(enum vmap_type type, void *start, void *end);
>> +void vfree_type(void *va, enum vmap_type type);
> Exposing the type (/region) parameter is quite unsafe, when mixed with
> the va.  What happens if someone passes in a va for one region, with a
> VMAP_$other ?

Good point, and the type can really be inferred from the VA. Just
that how this got done originally was a little unclean for my taste.

> How likely are we to gain a 3rd region?  My gut feeling is that it would
> be safer to hide all of the type/region bits in vmap.c (other than
> perhaps the _init() calls), and expose $VMAP_FOO_xen() functions in the API.

Well, while I can't give a concrete example, I do think that it's not
that unlikely for there to appear a 3rd region at some point.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.