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
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