Messages in this thread | | | Subject | Re: kmemleak panic | From | Marc Gonzalez <> | Date | Tue, 22 Jan 2019 15:02:25 +0100 |
| |
On 21/01/2019 18:42, Mike Rapoport wrote:
> If I understood correctly, the trouble comes from no-map range allocated in > early_init_dt_alloc_reserved_memory_arch(). > > There's indeed imbalance, because memblock_alloc() does kmemleak_alloc(), but > memblock_remove() does not do kmemleak_free(). > > I think the best way is to replace __memblock_alloc_base() with > memblock_find_in_range(), e.g something like: > > > diff --git a/drivers/of/of_reserved_mem.c b/drivers/of/of_reserved_mem.c > index 1977ee0adcb1..6807a1cffe55 100644 > --- a/drivers/of/of_reserved_mem.c > +++ b/drivers/of/of_reserved_mem.c > @@ -37,21 +37,16 @@ int __init __weak early_init_dt_alloc_reserved_memory_arch(phys_addr_t size, > */ > end = !end ? MEMBLOCK_ALLOC_ANYWHERE : end; > align = !align ? SMP_CACHE_BYTES : align; > - base = __memblock_alloc_base(size, align, end); > + base = memblock_find_in_range(size, align, start, end); > if (!base) > return -ENOMEM; > > - /* > - * Check if the allocated region fits in to start..end window > - */ > - if (base < start) { > - memblock_free(base, size); > - return -ENOMEM; > - } > - > *res_base = base; > if (nomap) > return memblock_remove(base, size); > + else > + return memblock_reserve(base, size); > + > return 0; > } >
Your patch solves the issue. \o/
| |