2021-10-11 16:21:54

by Vladimir Zapolskiy

Subject: Panic on kmemleak scan

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/[email protected]/T/#u
[2] https://lore.kernel.org/lkml/[email protected]/t/#m032124f36c07

--
Best wishes,
Vladimir

2021-10-12 06:11:07

by Mike Rapoport

Subject: Re: Panic on kmemleak scan

(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/[email protected]/T/#u
> [2] https://lore.kernel.org/lkml/[email protected]/t/#m032124f36c07
>
> --
> Best wishes,
> Vladimir

--
Sincerely yours,
Mike.

2021-10-12 08:26:59

by Vladimir Zapolskiy

Subject: Re: Panic on kmemleak scan

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 <[email protected]>

>> [...]
>> 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/[email protected]/T/#u
>> [2] https://lore.kernel.org/lkml/[email protected]/t/#m032124f36c07

--
Best wishes,
Vladimir