Re: [PATCH v4 10/34] vmap: Add vmalloc_cb and vfree_cb

["Jan Beulich" <JBeulich@suse.com>]

>>> On 15.03.16 at 18:56, <konrad.wilk@oracle.com> wrote:
> For those users who want to supply their own vmap callback.
> To be called _after_ the pages have been allocated and
> the vmap API is ready to hand out virtual addresses.
> 
> Instead of using the vmap ones it can call the callback
> which will be responsible for generating the virtual
> address.
> 
> This allows users (such as xSplice) to provide their own
> mechanism to set the page flags.
> The users (such as patch titled "xsplice: Implement payload
> loading") can wrap the calls to __vmap to accomplish this.
> 
> We also provide a mechanism for the calleer to squirrel
> the MFN array in case they want to modify the virtual
> addresses easily.
> 
> We also provide the free-ing code path - to use the vunmap_cb
> to take care of tearing down the virtual addresses.
> 
> Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>

To be honest, looking at this alone I'm not convinced. But I'll make
my final opinion dependent on seeing the actual use. Nevertheless
a few comments right away.

> @@ -238,11 +238,15 @@ void *vmalloc(size_t size)
>          mfn[i] = _mfn(page_to_mfn(pg));
>      }
>  
> -    va = vmap(mfn, pages);
> +    va = vmap_cb ? (vmap_cb)(mfn, pages) : vmap(mfn, pages);

Stray parentheses.

> @@ -266,7 +275,7 @@ void *vzalloc(size_t size)
>      return p;
>  }
>  
> -void vfree(void *va)
> +void vfree_cb(void *va, unsigned int nr_pages, vfree_cb_t vfree_cb_fnc)
>  {
>      unsigned int i, pages;
>      struct page_info *pg;
> @@ -275,8 +284,12 @@ void vfree(void *va)
>      if ( !va )
>          return;
>  
> -    pages = vm_size(va);
> -    ASSERT(pages);
> +    if ( !vfree_cb_fnc )
> +    {
> +        pages = vm_size(va);
> +        ASSERT(pages);
> +    } else

Coding style.

> +        pages = nr_pages;

So this "caller provides size" worries me in particular, the more that
this doesn't mirror anything the allocation side does. And if this
indeed is needed for usablity - why two variables with the same
purpose but different names (nr_pages and pages)?

> --- a/xen/include/xen/vmap.h
> +++ b/xen/include/xen/vmap.h
> @@ -12,9 +12,23 @@ void *__vmap(const mfn_t *mfn, unsigned int granularity,
>  void *vmap(const mfn_t *mfn, unsigned int nr);
>  void vunmap(const void *);
>  void *vmalloc(size_t size);
> +
> +/*
> + * Callback for vmalloc_cb to use when vmap-ing.
> + */
> +typedef void *(*vmap_cb_t)(const mfn_t *mfn, unsigned int pages);
> +void *vmalloc_cb(size_t size, vmap_cb_t vmap_cb, mfn_t **);

I think it is generally better to typedef such to be functions, not
pointers to functions, as that allows function declarations to be
made using the typedef (which in turn avoids having to touch
those declarations when the typedef changes).

> +void *vmalloc_cb(size_t size, vmap_cb_t vmap_cb, mfn_t **);

Doing so then also makes more obvious in such declarations that
the respective parameter is a pointer.

Jan


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