On Mon, 2009-08-10 at 15:05 +1000, Michael Ellerman wrote:
> We don't actually want kmemleak to track the lmb allocations, so we
> pass min_count as 0. However telling kmemleak about lmb allocations
> allows it to scan that memory for pointers to other memory that is
> tracked by kmemleak, ie. slab allocations etc.
> 
> Signed-off-by: Michael Ellerman <mich...@ellerman.id.au>
> ---
>  lib/lmb.c |    6 +++++-
>  1 files changed, 5 insertions(+), 1 deletions(-)
> 
> diff --git a/lib/lmb.c b/lib/lmb.c
> index e4a6482..dc10bc5 100644
> --- a/lib/lmb.c
> +++ b/lib/lmb.c
> @@ -352,8 +352,10 @@ u64 __init lmb_alloc_nid(u64 size, u64 align, int nid,
>               u64 ret = lmb_alloc_nid_region(&mem->region[i],
>                                              nid_range,
>                                              size, align, nid);
> -             if (ret != ~(u64)0)
> +             if (ret != ~(u64)0) {
> +                     kmemleak_alloc(__va(ret), size, 0, 0);
>                       return ret;
> +             }
>       }
>  
>       return lmb_alloc(size, align);
> @@ -412,6 +414,8 @@ u64 __init __lmb_alloc_base(u64 size, u64 align, u64 
> max_addr)
>                               /* this area isn't reserved, take it */
>                               if (lmb_add_region(&lmb.reserved, base, size) < 
> 0)
>                                       return 0;
> +
> +                             kmemleak_alloc(__va(base), size, 0, 0);
>                               return base;
>                       }
>                       res_base = lmb.reserved.region[j].base;

This needs an include of kmemleak.h for some configs, new patch coming.

cheers

Attachment: signature.asc
Description: This is a digitally signed message part

_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev

Reply via email to