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 <[email protected]> Cc: Tejun Heo <[email protected]> Cc: Andrew Morton <[email protected]> Signed-off-by: Grygorii Strashko <[email protected]> --- 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
