linux-kernel - Re: [PATCH] memblock: exclude NOMAP regions from kmemleak

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <089478ad-3755-b085-d9aa-c68e9792895c@quicinc.com>
Date:   Tue, 19 Oct 2021 11:06:11 -0400
From:   Qian Cai <quic_qiancai@...cinc.com>
To:     Catalin Marinas <catalin.marinas@....com>,
        Mike Rapoport <rppt@...nel.org>
CC:     <linux-mm@...ck.org>, Andrew Morton <akpm@...ux-foundation.org>,
        Mike Rapoport <rppt@...ux.ibm.com>,
        Vladimir Zapolskiy <vladimir.zapolskiy@...aro.org>,
        <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH] memblock: exclude NOMAP regions from kmemleak



On 10/19/2021 7:37 AM, Catalin Marinas wrote:
>>> I could help to confirm if it hangs right in the early boot somewhere if needed.
>>
>> The kernel config and a log of working kernel would help to start with.

http://lsbug.org/tmp/

> 
> I don't think there's much in the log other than the EFI stub above.
> 
>>> start_kernel()
>>>   setup_arch()
>>>     paging_init()
>>>       map_mem()
>>>         memblock_mark_nomap(
> 
> Is this actual trace? It would be good to know where exactly it got
> stuck.

No, I did not confirm anything yet. There is going to take a while to
figure out the exactly location that hang since even the early console
was not initialized yet. Any suggestion on how to debug in this case?

> 
>> So we have kmemleak_free_part_phys() here.
> 
> I wonder whether the memblock_mark_nomap() here is too early for
> kmemleak. We don't have the linear map created, though it shouldn't be
> an issue as the kernel sections are mapped. Also I think
> delete_object_part() in kmemleak.c would bail out early as there
> shouldn't be any prior memblock_alloc for this range.
>