Devicetree
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Jinjie Ruan" <ruanjinjie@huawei.com>
Cc: conor+dt@kernel.org, devicetree@vger.kernel.org, robh@kernel.org,
	krzk+dt@kernel.org
Subject: Re: [PATCH v13 10/15] x86/kexec: Use crash_prepare_headers() helper to simplify code
Date: Tue, 12 May 2026 05:48:10 +0000	[thread overview]
Message-ID: <20260512054810.B4FD8C2BCB0@smtp.kernel.org> (raw)
In-Reply-To: <20260511030454.1730881-11-ruanjinjie@huawei.com>

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Calling `crash_prepare_headers()` from the memory hotplug notifier causes a self-deadlock on `mem_hotplug_lock`.
--

commit 3ffc33a6d9cd3e7840883325b10a8172439b4b8f
Author: Jinjie Ruan <ruanjinjie@huawei.com>

x86/kexec: Use crash_prepare_headers() helper to simplify code

This commit replaces x86's custom prepare_elf_headers() with the generic
crash_prepare_headers() helper to handle cmem allocation, population, and
exclusion of crash ranges. The change implements the required
architecture-specific callbacks to support the generic core, reducing
code duplication.

> diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
> index 7fa6d45ebe3f7..10ef24611f2af 100644
> --- a/arch/x86/kernel/crash.c
> +++ b/arch/x86/kernel/crash.c

[ ... ]

> @@ -532,7 +465,7 @@ void arch_crash_handle_hotplug_event(struct kimage *image, void *arg)
>  	 * Create the new elfcorehdr reflecting the changes to CPU and/or
>  	 * memory resources.
>  	 */
> -	if (prepare_elf_headers(&elfbuf, &elfsz, &nr_mem_ranges)) {
> +	if (crash_prepare_headers(IS_ENABLED(CONFIG_X86_64), &elfbuf, &elfsz, NULL)) {

Will this cause a self-deadlock when called from the memory hotplug notifier?

During memory hotplug operations, the memory hotplug lock is held for
write before notifying the chain. For instance:

online_pages()
    mem_hotplug_begin() // takes mem_hotplug_lock for write
    ...
    memory_notify(MEM_ONLINE, ...)
        crash_memhp_notifier()
            arch_crash_handle_hotplug_event()
                crash_prepare_headers()

Then inside crash_prepare_headers() from kernel/crash_core.c:

int crash_prepare_headers(int need_kernel_map, void **addr, unsigned long *sz,
			  unsigned long *nr_mem_ranges)
{
	unsigned int max_nr_ranges;
	struct crash_mem *cmem;
	int ret;

	get_online_mems();

get_online_mems() attempts to acquire the mem_hotplug_lock for read. 

Since the percpu_rw_semaphore does not support recursive read-after-write
locking by the same thread, won't this block indefinitely and result in a
deadlock?

>  		pr_err("unable to create new elfcorehdr");
>  		goto out;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260511030454.1730881-1-ruanjinjie@huawei.com?part=10

  reply	other threads:[~2026-05-12  5:48 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-05-11  3:04 [PATCH v13 00/15] arm64/riscv: Add support for crashkernel CMA reservation Jinjie Ruan
2026-05-11  3:04 ` [PATCH v13 01/15] riscv: kexec_file: Fix crashk_low_res not exclude bug Jinjie Ruan
2026-05-11  3:04 ` [PATCH v13 02/15] powerpc/crash: Fix possible memory leak in update_crash_elfcorehdr() Jinjie Ruan
2026-05-11  3:04 ` [PATCH v13 03/15] x86/kexec: Fix potential buffer overflow in prepare_elf_headers() Jinjie Ruan
2026-05-12  0:18   ` sashiko-bot
2026-05-11  3:04 ` [PATCH v13 04/15] arm64: kexec_file: " Jinjie Ruan
2026-05-11  9:46   ` Breno Leitao
2026-05-11 11:30     ` Jinjie Ruan
2026-05-11 12:30       ` Breno Leitao
2026-05-12  0:45   ` sashiko-bot
2026-05-11  3:04 ` [PATCH v13 05/15] riscv: " Jinjie Ruan
2026-05-11  3:04 ` [PATCH v13 06/15] LoongArch: kexec: " Jinjie Ruan
2026-05-11  3:04 ` [PATCH v13 07/15] powerpc/crash: sort crash memory ranges before preparing elfcorehdr Jinjie Ruan
2026-05-11  3:04 ` [PATCH v13 08/15] crash: Add crash_prepare_headers() to exclude crash kernel memory Jinjie Ruan
2026-05-12  4:23   ` sashiko-bot
2026-05-11  3:04 ` [PATCH v13 09/15] arm64: kexec_file: Use crash_prepare_headers() helper to simplify code Jinjie Ruan
2026-05-11  3:04 ` [PATCH v13 10/15] x86/kexec: " Jinjie Ruan
2026-05-12  5:48   ` sashiko-bot [this message]
2026-05-11  3:04 ` [PATCH v13 11/15] riscv: kexec_file: " Jinjie Ruan
2026-05-11  3:04 ` [PATCH v13 12/15] LoongArch: kexec: " Jinjie Ruan
2026-05-11  3:04 ` [PATCH v13 13/15] crash: Use crash_exclude_core_ranges() on powerpc Jinjie Ruan
2026-05-11  3:04 ` [PATCH v13 14/15] arm64: kexec: Add support for crashkernel CMA reservation Jinjie Ruan
2026-05-11  3:04 ` [PATCH v13 15/15] riscv: " Jinjie Ruan

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=20260512054810.B4FD8C2BCB0@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=conor+dt@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=krzk+dt@kernel.org \
    --cc=robh@kernel.org \
    --cc=ruanjinjie@huawei.com \
    --cc=sashiko@lists.linux.dev \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox