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

[Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>]

On Fri, Apr 08, 2016 at 11:19:24AM -0600, Jan Beulich wrote:
> >>> On 08.04.16 at 16:22, <andrew.cooper3@citrix.com> 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.

OK, then let just expose the vmalloc_xen, and vfree_xen along with
vmap_init_type.

The rest will be part of the vmalloc.c file.

Albeit I will leave __vmap with the type..
> 
> > 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.
> 
> Jan
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel