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@xxxxxxxxxx> Cc: Tejun Heo <tj@xxxxxxxxxx> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Signed-off-by: Grygorii Strashko <grygorii.strashko@xxxxxx> --- 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 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>