summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/mem-phys-addr.py
diff options
context:
space:
mode:
authorCatalin Marinas <catalin.marinas@arm.com>2025-01-27 21:42:33 +0300
committerAndrew Morton <akpm@linux-foundation.org>2025-02-01 14:53:25 +0300
commit488b5b9eca68497b533ced059be5eff19578bbca (patch)
treec3f127e5ecc05f9f39ca6497d6a05d5f9408cc1b /tools/perf/scripts/python/mem-phys-addr.py
parentc3d8ced37e6f724cdcc5382b40858a2136c47591 (diff)
downloadlinux-488b5b9eca68497b533ced059be5eff19578bbca.tar.xz
mm: kmemleak: fix upper boundary check for physical address objects
Memblock allocations are registered by kmemleak separately, based on their physical address. During the scanning stage, it checks whether an object is within the min_low_pfn and max_low_pfn boundaries and ignores it otherwise. With the recent addition of __percpu pointer leak detection (commit 6c99d4eb7c5e ("kmemleak: enable tracking for percpu pointers")), kmemleak started reporting leaks in setup_zone_pageset() and setup_per_cpu_pageset(). These were caused by the node_data[0] object (initialised in alloc_node_data()) ending on the PFN_PHYS(max_low_pfn) boundary. The non-strict upper boundary check introduced by commit 84c326299191 ("mm: kmemleak: check physical address when scan") causes the pg_data_t object to be ignored (not scanned) and the __percpu pointers it contains to be reported as leaks. Make the max_low_pfn upper boundary check strict when deciding whether to ignore a physical address object and not scan it. Link: https://lkml.kernel.org/r/20250127184233.2974311-1-catalin.marinas@arm.com Fixes: 84c326299191 ("mm: kmemleak: check physical address when scan") Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Reported-by: Jakub Kicinski <kuba@kernel.org> Tested-by: Matthieu Baerts (NGI0) <matttbe@kernel.org> Cc: Patrick Wang <patrick.wang.shcn@gmail.com> Cc: <stable@vger.kernel.org> [6.0.x] Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Diffstat (limited to 'tools/perf/scripts/python/mem-phys-addr.py')
0 files changed, 0 insertions, 0 deletions