Re: [Xen-devel] [PATCH V3 3/8] xen/common: Introduce _xrealloc function

[Paul Durrant <Paul.Durrant@xxxxxxxxxx>]

> -----Original Message-----
> From: Xen-devel <xen-devel-bounces@xxxxxxxxxxxxxxxxxxxx> On Behalf Of 
> Oleksandr Tyshchenko
> Sent: 20 August 2019 19:10
> To: xen-devel@xxxxxxxxxxxxxxxxxxxx
> Cc: sstabellini@xxxxxxxxxx; Wei Liu <wl@xxxxxxx>; Konrad Rzeszutek Wilk 
> <konrad.wilk@xxxxxxxxxx>;
> George Dunlap <George.Dunlap@xxxxxxxxxx>; Andrew Cooper 
> <Andrew.Cooper3@xxxxxxxxxx>; Ian Jackson
> <Ian.Jackson@xxxxxxxxxx>; Tim (Xen.org) <tim@xxxxxxx>; Oleksandr Tyshchenko
> <oleksandr_tyshchenko@xxxxxxxx>; julien.grall@xxxxxxx; Jan Beulich 
> <jbeulich@xxxxxxxx>;
> Volodymyr_Babchuk@xxxxxxxx
> Subject: [Xen-devel] [PATCH V3 3/8] xen/common: Introduce _xrealloc function
> 
> From: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
> 
> This patch introduces type-unsafe function which besides
> re-allocation handles the following corner cases:
> 1. if requested size is zero, it will behave like xfree
> 2. if incoming pointer is not valid (NULL or ZERO_BLOCK_PTR),
>    it will behave like xmalloc
> 
> If both pointer and size are valid the function will re-allocate and
> copy only if requested size doesn't fit in already allocated space.
> 
> Subsequent patch will add type-safe helper macros.
> 
> Signed-off-by: Oleksandr Tyshchenko <oleksandr_tyshchenko@xxxxxxxx>
> CC: Andrew Cooper <andrew.cooper3@xxxxxxxxxx>
> CC: George Dunlap <George.Dunlap@xxxxxxxxxxxxx>
> CC: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>
> CC: Jan Beulich <jbeulich@xxxxxxxx>
> CC: Julien Grall <julien.grall@xxxxxxx>
> CC: Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>
> CC: Stefano Stabellini <sstabellini@xxxxxxxxxx>
> CC: Tim Deegan <tim@xxxxxxx>
> CC: Wei Liu <wl@xxxxxxx>
> 
> ---
> Changes since RFC:
>    - behave like xmalloc if incoming pointer is ZERO_BLOCK_PTR or NULL
>    - return ZERO_BLOCK_PTR after xfree if requested size is zero
>    - add patch description
>    - use allocator internals to recognize current size of
>      the incoming pointer
>    - do not re-allocate and copy if requested size fits in already
>      allocated space
> 
>    ...
> 
>    Original patch was initially posted by Sameer Goel:
>    https://lists.xen.org/archives/html/xen-devel/2017-06/msg00858.html
> 
>    This could be considered as another attempt to add it:
>    https://www.mail-archive.com/kexec@xxxxxxxxxxxxxxxxxxx/msg21335.html
> 
>    [As it was previously discussed with Julien in IRC]
> 
>    The reason for this patch to be an RFC is that patch itself is not
>    completely correct and I don't fully understand what/how should
>    be done for this patch to be accepted. Or whether community even
>    wants this to go in. So, to avoid bike shedding, the first target is
>    to collect feedback.
> 
>    For everyone who wants more details why this is needed and
>    where used, please see next patch of this thread:
>    "iommu/arm: Add lightweight iommu_fwspec support"
> 
>    In a nutshell, the upcoming "iommu_fwspec" support on ARM
>    is going to use xrealloc to expand an array for device IDs.
>    We really want to have "iommu_fwspec" support which will give us
>    a generic abstract way to add new device to the IOMMU based on
>    the generic IOMMU DT binding.
> ---
>  xen/common/xmalloc_tlsf.c | 45 +++++++++++++++++++++++++++++++++++++++++++++
>  xen/include/xen/xmalloc.h |  1 +
>  2 files changed, 46 insertions(+)
> 
> diff --git a/xen/common/xmalloc_tlsf.c b/xen/common/xmalloc_tlsf.c
> index e98ad65..eecae2e 100644
> --- a/xen/common/xmalloc_tlsf.c
> +++ b/xen/common/xmalloc_tlsf.c
> @@ -598,6 +598,51 @@ void *_xzalloc(unsigned long size, unsigned long align)
>      return p ? memset(p, 0, size) : p;
>  }
> 
> +void *_xrealloc(void *ptr, unsigned long size, unsigned long align)
> +{
> +    unsigned long curr_size, tmp_size;
> +    void *p;
> +
> +    if ( !size )
> +    {
> +        xfree(ptr);
> +        return ZERO_BLOCK_PTR;
> +    }
> +
> +    if ( ptr == NULL || ptr == ZERO_BLOCK_PTR )
> +        return _xmalloc(size, align);
> +
> +    if ( !((unsigned long)ptr & (PAGE_SIZE - 1)) )
> +        curr_size = PFN_ORDER(virt_to_page(ptr)) << PAGE_SHIFT;
> +    else
> +    {
> +        struct bhdr *b;
> +        b = (struct bhdr *)((char *)ptr - BHDR_OVERHEAD);
> +        curr_size = b->size & BLOCK_SIZE_MASK;
> +    }

That seconds clause is not going to give you the block size if the previous 
allocation had alignment padding. You'll need to check the FREE_BLOCK bit to 
tell whether it's a real block header or the 'fake' alignment header and then 
maybe walk backwards onto the real header. See the code in xfree(). You should 
also check whether the new requested alignment is compatible with the existing 
block alignment

  Paul

> +
> +    ASSERT((align & (align - 1)) == 0);
> +    if ( align < MEM_ALIGN )
> +        align = MEM_ALIGN;
> +    tmp_size = size + align - MEM_ALIGN;
> +
> +    if ( tmp_size < PAGE_SIZE )
> +        tmp_size = ( tmp_size < MIN_BLOCK_SIZE ) ? MIN_BLOCK_SIZE :
> +            ROUNDUP_SIZE(tmp_size);
> +
> +    if ( tmp_size <= curr_size ) /* fits in current block */
> +        return ptr;
> +
> +    p = _xmalloc(size, align);
> +    if ( p )
> +    {
> +        memcpy(p, ptr, min(curr_size, size));
> +        xfree(ptr);
> +    }
> +
> +    return p;
> +}
> +
>  void xfree(void *p)
>  {
>      struct bhdr *b;
> diff --git a/xen/include/xen/xmalloc.h b/xen/include/xen/xmalloc.h
> index f075d2d..831152f 100644
> --- a/xen/include/xen/xmalloc.h
> +++ b/xen/include/xen/xmalloc.h
> @@ -51,6 +51,7 @@ extern void xfree(void *);
>  /* Underlying functions */
>  extern void *_xmalloc(unsigned long size, unsigned long align);
>  extern void *_xzalloc(unsigned long size, unsigned long align);
> +extern void *_xrealloc(void *ptr, unsigned long size, unsigned long align);
> 
>  static inline void *_xmalloc_array(
>      unsigned long size, unsigned long align, unsigned long num)
> --
> 2.7.4
> 
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxx
> https://lists.xenproject.org/mailman/listinfo/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel