All of lore.kernel.org
 help / color / mirror / Atom feed
From: Qian Cai <quic_qiancai@quicinc.com>
To: Catalin Marinas <catalin.marinas@arm.com>,
	Mike Rapoport <rppt@kernel.org>
Cc: <linux-mm@kvack.org>, Andrew Morton <akpm@linux-foundation.org>,
	Mike Rapoport <rppt@linux.ibm.com>,
	Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>,
	<linux-kernel@vger.kernel.org>,
	Linus Torvalds <torvalds@linux-foundation.org>
Subject: Re: [PATCH] memblock: exclude NOMAP regions from kmemleak
Date: Tue, 19 Oct 2021 11:06:11 -0400	[thread overview]
Message-ID: <089478ad-3755-b085-d9aa-c68e9792895c@quicinc.com> (raw)
In-Reply-To: <YW6t5tBe/IjSYWn3@arm.com>



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.
> 

  reply	other threads:[~2021-10-19 15:06 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-13  5:47 [PATCH] memblock: exclude NOMAP regions from kmemleak Mike Rapoport
2021-10-13  7:45 ` Catalin Marinas
2021-10-13 11:35   ` Mike Rapoport
2021-10-19  3:55 ` Qian Cai
2021-10-19  5:45   ` Mike Rapoport
2021-10-19 11:37     ` Catalin Marinas
2021-10-19 15:06       ` Qian Cai [this message]
2021-10-19 15:53         ` Catalin Marinas
2021-10-19 17:59           ` Qian Cai
2021-10-19 18:33             ` Mike Rapoport
2021-10-20  7:38               ` Mike Rapoport
2021-10-20  8:18                 ` Catalin Marinas
2021-10-20  8:42                   ` Mike Rapoport
2021-10-20  9:33                     ` Catalin Marinas
2021-10-20 10:13                 ` Catalin Marinas
2021-10-20 10:39                   ` Mike Rapoport
2021-10-19  4:21 ` Anshuman Khandual

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=089478ad-3755-b085-d9aa-c68e9792895c@quicinc.com \
    --to=quic_qiancai@quicinc.com \
    --cc=akpm@linux-foundation.org \
    --cc=catalin.marinas@arm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=rppt@kernel.org \
    --cc=rppt@linux.ibm.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vladimir.zapolskiy@linaro.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
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.