* Panic on kmemleak scan
@ 2021-10-11 11:23 Vladimir Zapolskiy
2021-10-12 6:08 ` Mike Rapoport
0 siblings, 1 reply; 3+ messages in thread
From: Vladimir Zapolskiy @ 2021-10-11 11:23 UTC (permalink / raw)
To: Mike Rapoport; +Cc: lkml, linux-mm
Hello Mike,
commit a7259df767 ("memblock: make memblock_find_in_range method private") [1]
invokes a kernel panic while running kmemleak on OF platforms with nomaped
regions, basically it's similar to an issue reported and fixed earlier by [2]:
Unable to handle kernel paging request at virtual address ffff000021e00000
[...]
scan_block+0x64/0x170
scan_gray_list+0xe8/0x17c
kmemleak_scan+0x270/0x514
kmemleak_write+0x34c/0x4ac
I believe it would be a trivial problem to correct for you, thank you in
advance!
[1] https://lore.kernel.org/all/20210816122622.30279-1-rppt@kernel.org/T/#u
[2] https://lore.kernel.org/lkml/20190119132832.GA29881@MBP.local/t/#m032124f36c07
--
Best wishes,
Vladimir
^ permalink raw reply [flat|nested] 3+ messages in thread* Re: Panic on kmemleak scan 2021-10-11 11:23 Panic on kmemleak scan Vladimir Zapolskiy @ 2021-10-12 6:08 ` Mike Rapoport 2021-10-12 8:21 ` Vladimir Zapolskiy 0 siblings, 1 reply; 3+ messages in thread From: Mike Rapoport @ 2021-10-12 6:08 UTC (permalink / raw) To: Vladimir Zapolskiy; +Cc: lkml, linux-mm, Catalin Marinas (added Catalin) On Mon, Oct 11, 2021 at 02:23:31PM +0300, Vladimir Zapolskiy wrote: > Hello Mike, > > commit a7259df767 ("memblock: make memblock_find_in_range method private") [1] > invokes a kernel panic while running kmemleak on OF platforms with nomaped > regions, basically it's similar to an issue reported and fixed earlier by [2]: > > Unable to handle kernel paging request at virtual address ffff000021e00000 Does this virtual address correspond to a nomap area? Can you check if this patch helps: diff --git a/mm/memblock.c b/mm/memblock.c index 184dcd2e5d99..5c3503c98b2f 100644 --- a/mm/memblock.c +++ b/mm/memblock.c @@ -936,7 +936,12 @@ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size) */ int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size) { - return memblock_setclr_flag(base, size, 1, MEMBLOCK_NOMAP); + int ret = memblock_setclr_flag(base, size, 1, MEMBLOCK_NOMAP); + + if (!ret) + kmemleak_free_part_phys(base, size); + + return ret; } /** > [...] > scan_block+0x64/0x170 > scan_gray_list+0xe8/0x17c > kmemleak_scan+0x270/0x514 > kmemleak_write+0x34c/0x4ac > > I believe it would be a trivial problem to correct for you, thank you in > advance! > > [1] https://lore.kernel.org/all/20210816122622.30279-1-rppt@kernel.org/T/#u > [2] https://lore.kernel.org/lkml/20190119132832.GA29881@MBP.local/t/#m032124f36c07 > > -- > Best wishes, > Vladimir -- Sincerely yours, Mike. ^ permalink raw reply related [flat|nested] 3+ messages in thread
* Re: Panic on kmemleak scan 2021-10-12 6:08 ` Mike Rapoport @ 2021-10-12 8:21 ` Vladimir Zapolskiy 0 siblings, 0 replies; 3+ messages in thread From: Vladimir Zapolskiy @ 2021-10-12 8:21 UTC (permalink / raw) To: Mike Rapoport; +Cc: lkml, linux-mm, Catalin Marinas Hi Mike, On 10/12/21 9:08 AM, Mike Rapoport wrote: > (added Catalin) > > On Mon, Oct 11, 2021 at 02:23:31PM +0300, Vladimir Zapolskiy wrote: >> Hello Mike, >> >> commit a7259df767 ("memblock: make memblock_find_in_range method private") [1] >> invokes a kernel panic while running kmemleak on OF platforms with nomaped >> regions, basically it's similar to an issue reported and fixed earlier by [2]: >> >> Unable to handle kernel paging request at virtual address ffff000021e00000 > > Does this virtual address correspond to a nomap area? Yes, it does: OF: reserved mem: allocated memory for 'rmtfs@86700000' node: base 0x00000000a1e00000, size 2 MiB and 'rmtfs@86700000' device node has a 'no-map' property. Also: # echo dump=0xffff000021e00000 > /sys/kernel/debug/kmemleak [ 35.679096] kmemleak: Object 0xffff000021e00000 (size 2097152): [ 35.679172] kmemleak: comm "swapper", pid 0, jiffies 4294892296 [ 35.683860] kmemleak: min_count = 0 [ 35.690106] kmemleak: count = 0 [ 35.693752] kmemleak: flags = 0x1 [ 35.697050] kmemleak: checksum = 0 [ 35.700350] kmemleak: backtrace: [ 35.704170] kmemleak_alloc_phys+0x2c/0x40 [ 35.707381] memblock_alloc_range_nid+0x150/0x170 [ 35.711810] memblock_phys_alloc_range+0xb8/0xc8 [ 35.716931] early_init_dt_alloc_reserved_memory_arch+0x40/0x94 [ 35.721968] __reserved_mem_alloc_size+0x200/0x308 [ 35.727955] fdt_init_reserved_mem+0x154/0x284 [ 35.733164] early_init_fdt_scan_reserved_mem+0x80/0xfc [ 35.737939] arm64_memblock_init+0x23c/0x278 [ 35.743406] setup_arch+0x18c/0x228 [ 35.748266] start_kernel+0x94/0x610 [ 35.751825] __primary_switched+0xc0/0xc8 > Can you check if this patch helps: > > diff --git a/mm/memblock.c b/mm/memblock.c > index 184dcd2e5d99..5c3503c98b2f 100644 > --- a/mm/memblock.c > +++ b/mm/memblock.c > @@ -936,7 +936,12 @@ int __init_memblock memblock_mark_mirror(phys_addr_t base, phys_addr_t size) > */ > int __init_memblock memblock_mark_nomap(phys_addr_t base, phys_addr_t size) > { > - return memblock_setclr_flag(base, size, 1, MEMBLOCK_NOMAP); > + int ret = memblock_setclr_flag(base, size, 1, MEMBLOCK_NOMAP); > + > + if (!ret) > + kmemleak_free_part_phys(base, size); > + > + return ret; > } > > /** > The change fixes the issue, thank you! The object is also gone from being under kmemleak: # echo dump=0xffff000021e00000 > /sys/kernel/debug/kmemleak kmemleak: Unknown object at 0xffff000021e00000 Please feel free to add my Tested-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org> >> [...] >> scan_block+0x64/0x170 >> scan_gray_list+0xe8/0x17c >> kmemleak_scan+0x270/0x514 >> kmemleak_write+0x34c/0x4ac >> >> I believe it would be a trivial problem to correct for you, thank you in >> advance! >> >> [1] https://lore.kernel.org/all/20210816122622.30279-1-rppt@kernel.org/T/#u >> [2] https://lore.kernel.org/lkml/20190119132832.GA29881@MBP.local/t/#m032124f36c07 -- Best wishes, Vladimir ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2021-10-12 8:21 UTC | newest] Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-10-11 11:23 Panic on kmemleak scan Vladimir Zapolskiy 2021-10-12 6:08 ` Mike Rapoport 2021-10-12 8:21 ` Vladimir Zapolskiy
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.