Messages in this thread Patch in this message | | | From | Grygorii Strashko <> | Subject | [PATCH 1/2] mm/memblock: add more comments in code | Date | Wed, 11 Dec 2013 17:36:13 +0200 |
| |
Add additional description on: - why warning is produced in case if slab is ready - why kmemleak_alloc is called for each allocated memory block
Cc: Yinghai Lu <yinghai@kernel.org> Cc: Tejun Heo <tj@kernel.org> Cc: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Grygorii Strashko <grygorii.strashko@ti.com> ---
It's additional change on top of the memblock series https://lkml.org/lkml/2013/12/9/715
mm/memblock.c | 9 ++++++++- 1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/mm/memblock.c b/mm/memblock.c index d03d50a..974f0d3 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -985,6 +985,11 @@ static void * __init memblock_virt_alloc_internal( pr_warn("%s: usage of MAX_NUMNODES is depricated. Use NUMA_NO_NODE\n", __func__); + /* + * Detect any accidental use of these APIs after slab is ready, as at + * this moment memblock may be deinitialized already and its + * internal data may be destroyed (after execution of free_all_bootmem) + */ if (WARN_ON_ONCE(slab_is_available())) return kzalloc_node(size, GFP_NOWAIT, nid); @@ -1021,7 +1026,9 @@ done: /* * The min_count is set to 0 so that bootmem allocated blocks - * are never reported as leaks. + * are never reported as leaks. This is because many of these blocks + * are only referred via the physical address which is not + * looked up by kmemleak. */ kmemleak_alloc(ptr, size, 0, 0); -- 1.7.9.5
| |