All of lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: m.szyprowski@samsung.com, "Wandun Chen" <chenwandun1@gmail.com>,
	baoquan.he@linux.dev, robh@kernel.org, rppt@kernel.org
Cc: devicetree@vger.kernel.org, ruirui.yang@linux.dev,
	linux-arm-kernel@lists.infradead.org, alex@ghiti.fr,
	pjw@kernel.org, tglx@kernel.org, aou@eecs.berkeley.edu,
	bp@alien8.de, hpa@zytor.com, akpm@linux-foundation.org,
	mingo@redhat.com, linux-kernel@vger.kernel.org,
	dave.hansen@linux.intel.com, saravanak@kernel.org,
	x86@kernel.org, will@kernel.org, kexec@lists.infradead.org,
	linux-riscv@lists.infradead.org, linux-mm@kvack.org,
	chenhuacai@kernel.org, iommu@lists.linux.dev,
	mark.rutland@arm.com, loongarch@lists.linux.dev,
	robin.murphy@arm.com, kernel@xen0n.name, pratyush@kernel.org,
	catalin.marinas@arm.com, palmer@dabbelt.com, conor+dt@kernel.org,
	pasha.tatashin@soleen.com
Subject: Re: [PATCH v7 3/9] crash_core: serialize crash header preparation against hotplug
Date: Tue, 22 Sep 2026 09:03:05 +0000	[thread overview]
Message-ID: <20260922090306.542831F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260922084256.1515554-4-chenwandun1@gmail.com>

> From: Wandun Chen <chenwandun@lixiang.com>
> 
> crash_prepare_headers() counts memory ranges before populating the
> allocated crash_mem array. The weak implementation used by ARM64,
> RISC-V and LoongArch walks memblock.memory, while x86 performs the same
> two-pass operation over system RAM resources. Concurrent memory hotplug
> can change range source between the two walks and make the populate
> pass overflow cmem->ranges.
> 
> Take device_hotplug_lock when preparing crash headers during
> kexec_file_load(). The x86 memory hotplug path already takes
> device_hotplug_lock, so call __crash_prepare_headers() directly
> to avoid recursive locking.
> 
> Sashiko reported this issue in [1].
> 
> Fixes: 3751e728cef2 ("arm64: kexec_file: add crash dump support")
> Fixes: 1bcca8620a91 ("LoongArch: Add crash dump support for kexec_file")
> Fixes: 8acea455fafa ("RISC-V: Support for kexec_file on panic")
> Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922084256.1515554-1-chenwandun1@gmail.com?part=3



WARNING: multiple messages have this Message-ID (diff)
From: sashiko-bot@kernel.org
To: m.szyprowski@samsung.com, "Wandun Chen" <chenwandun1@gmail.com>,
	baoquan.he@linux.dev, robh@kernel.org, rppt@kernel.org
Cc: devicetree@vger.kernel.org, ruirui.yang@linux.dev,
	linux-arm-kernel@lists.infradead.org, alex@ghiti.fr,
	pjw@kernel.org, tglx@kernel.org, aou@eecs.berkeley.edu,
	bp@alien8.de, hpa@zytor.com, akpm@linux-foundation.org,
	mingo@redhat.com, linux-kernel@vger.kernel.org,
	dave.hansen@linux.intel.com, saravanak@kernel.org,
	x86@kernel.org, will@kernel.org, kexec@lists.infradead.org,
	linux-riscv@lists.infradead.org, linux-mm@kvack.org,
	chenhuacai@kernel.org, iommu@lists.linux.dev,
	mark.rutland@arm.com, loongarch@lists.linux.dev,
	robin.murphy@arm.com, kernel@xen0n.name, pratyush@kernel.org,
	catalin.marinas@arm.com, palmer@dabbelt.com, conor+dt@kernel.org,
	pasha.tatashin@soleen.com
Subject: Re: [PATCH v7 3/9] crash_core: serialize crash header preparation against hotplug
Date: Tue, 22 Sep 2026 09:03:05 +0000	[thread overview]
Message-ID: <20260922090306.542831F000FF@smtp.kernel.org> (raw)
In-Reply-To: <20260922084256.1515554-4-chenwandun1@gmail.com>

> From: Wandun Chen <chenwandun@lixiang.com>
> 
> crash_prepare_headers() counts memory ranges before populating the
> allocated crash_mem array. The weak implementation used by ARM64,
> RISC-V and LoongArch walks memblock.memory, while x86 performs the same
> two-pass operation over system RAM resources. Concurrent memory hotplug
> can change range source between the two walks and make the populate
> pass overflow cmem->ranges.
> 
> Take device_hotplug_lock when preparing crash headers during
> kexec_file_load(). The x86 memory hotplug path already takes
> device_hotplug_lock, so call __crash_prepare_headers() directly
> to avoid recursive locking.
> 
> Sashiko reported this issue in [1].
> 
> Fixes: 3751e728cef2 ("arm64: kexec_file: add crash dump support")
> Fixes: 1bcca8620a91 ("LoongArch: Add crash dump support for kexec_file")
> Fixes: 8acea455fafa ("RISC-V: Support for kexec_file on panic")
> Fixes: dd5f726076cc ("kexec: support for kexec on panic using new system call")
> Signed-off-by: Wandun Chen <chenwandun@lixiang.com>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260922084256.1515554-1-chenwandun1@gmail.com?part=3


_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-09-22  9:03 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-22  8:42 [PATCH v7 0/9] kdump: reduce vmcore size and capture time Wandun Chen
2026-09-22  8:42 ` Wandun Chen
2026-09-22  8:42 ` [PATCH v7 1/9] riscv: build crash_mem ranges from memblock instead of resource tree Wandun Chen
2026-09-22  8:42   ` Wandun Chen
2026-09-22  8:59   ` sashiko-bot
2026-09-22  8:59     ` sashiko-bot
2026-09-22  8:42 ` [PATCH v7 2/9] crash_core: fold duplicated memblock arch hooks into the weak default Wandun Chen
2026-09-22  8:42   ` Wandun Chen
2026-09-22  8:56   ` sashiko-bot
2026-09-22  8:56     ` sashiko-bot
2026-09-22  8:42 ` [PATCH v7 3/9] crash_core: serialize crash header preparation against hotplug Wandun Chen
2026-09-22  8:42   ` Wandun Chen
2026-09-22  9:03   ` sashiko-bot [this message]
2026-09-22  9:03     ` sashiko-bot
2026-09-22  8:42 ` [PATCH v7 4/9] crash_core: replace for_each_mem_range() with for_each_mem_region() Wandun Chen
2026-09-22  8:42   ` Wandun Chen
2026-09-22  8:56   ` sashiko-bot
2026-09-22  8:56     ` sashiko-bot
2026-09-22  8:42 ` [PATCH v7 5/9] memblock: introduce MEMBLOCK_NODUMP flag Wandun Chen
2026-09-22  8:42   ` Wandun Chen
2026-09-22  9:02   ` sashiko-bot
2026-09-22  9:02     ` sashiko-bot
2026-09-22  8:42 ` [PATCH v7 6/9] of: reserved_mem: add dumpable flag to opt-in vmcore Wandun Chen
2026-09-22  8:42   ` Wandun Chen
2026-09-22  8:54   ` sashiko-bot
2026-09-22  8:54     ` sashiko-bot
2026-09-22  8:42 ` [PATCH v7 7/9] of: reserved_mem: mark /reserved-memory entries with MEMBLOCK_NODUMP Wandun Chen
2026-09-22  8:42   ` Wandun Chen
2026-09-22  9:01   ` sashiko-bot
2026-09-22  9:01     ` sashiko-bot
2026-09-22  8:42 ` [PATCH v7 8/9] of: reserved_mem: mark /memreserve/ entries as MEMBLOCK_NODUMP Wandun Chen
2026-09-22  8:42   ` Wandun Chen
2026-09-22  9:04   ` sashiko-bot
2026-09-22  9:04     ` sashiko-bot
2026-09-22  8:42 ` [PATCH v7 9/9] crash_core: skip MEMBLOCK_NODUMP regions when building vmcore ELF header Wandun Chen
2026-09-22  8:42   ` Wandun Chen
2026-09-22  9:02   ` sashiko-bot
2026-09-22  9:02     ` sashiko-bot
2026-10-02  8:17 ` [PATCH v7 0/9] kdump: reduce vmcore size and capture time Mike Rapoport
2026-10-02  8:17   ` Mike Rapoport
2026-10-09  3:04   ` Wandun
2026-10-09  3:04     ` Wandun
2026-10-09 16:26     ` Mike Rapoport
2026-10-09 16:26       ` Mike Rapoport
2026-10-09 17:10       ` Rob Herring
2026-10-09 17:10         ` Rob Herring

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=20260922090306.542831F000FF@smtp.kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=alex@ghiti.fr \
    --cc=aou@eecs.berkeley.edu \
    --cc=baoquan.he@linux.dev \
    --cc=bp@alien8.de \
    --cc=catalin.marinas@arm.com \
    --cc=chenhuacai@kernel.org \
    --cc=chenwandun1@gmail.com \
    --cc=conor+dt@kernel.org \
    --cc=dave.hansen@linux.intel.com \
    --cc=devicetree@vger.kernel.org \
    --cc=hpa@zytor.com \
    --cc=iommu@lists.linux.dev \
    --cc=kernel@xen0n.name \
    --cc=kexec@lists.infradead.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=loongarch@lists.linux.dev \
    --cc=m.szyprowski@samsung.com \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=palmer@dabbelt.com \
    --cc=pasha.tatashin@soleen.com \
    --cc=pjw@kernel.org \
    --cc=pratyush@kernel.org \
    --cc=robh@kernel.org \
    --cc=robin.murphy@arm.com \
    --cc=rppt@kernel.org \
    --cc=ruirui.yang@linux.dev \
    --cc=saravanak@kernel.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=tglx@kernel.org \
    --cc=will@kernel.org \
    --cc=x86@kernel.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.