From: Will Deacon <will@kernel.org>
To: Coiby Xu <coxu@redhat.com>
Cc: kexec@lists.infradead.org, linux-arm-kernel@lists.infradead.org,
Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com>,
Baoquan he <bhe@redhat.com>, Dave Young <dyoung@redhat.com>,
Kairui Song <ryncsn@gmail.com>,
Pingfan Liu <kernelfans@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Krzysztof Kozlowski <krzk@kernel.org>,
Rob Herring <robh@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Saravana Kannan <saravanak@kernel.org>,
open list <linux-kernel@vger.kernel.org>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE"
<devicetree@vger.kernel.org>
Subject: Re: [PATCH v3] arm64/kdump: pass dm-crypt keys to kdump kernel
Date: Mon, 26 Jan 2026 14:36:08 +0000 [thread overview]
Message-ID: <aXd72PcvvFsIFXO2@willie-the-truck> (raw)
In-Reply-To: <20260123081326.1362666-1-coxu@redhat.com>
On Fri, Jan 23, 2026 at 04:13:25PM +0800, Coiby Xu wrote:
> CONFIG_CRASH_DM_CRYPT has been introduced to support LUKS-encrypted
> device dump target by addressing two challenges [1],
> - Kdump kernel may not be able to decrypt the LUKS partition. For some
> machines, a system administrator may not have a chance to enter the
> password to decrypt the device in kdump initramfs after the 1st kernel
> crashes
>
> - LUKS2 by default use the memory-hard Argon2 key derivation function
> which is quite memory-consuming compared to the limited memory reserved
> for kdump.
>
> To also enable this feature for ARM64, we only need to add device tree
> property dmcryptkeys [2] as similar to elfcorehdr to pass the memory
> address of the stored info of dm-crypt keys to the kdump kernel. Since
> this property is only needed by the kdump kenrel, it won't be exposed to
> user space.
>
> [1] https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/
> [2] https://github.com/devicetree-org/dt-schema/pull/181
>
> Cc: Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com>
> Cc: Baoquan he <bhe@redhat.com>
> Cc: Dave Young <dyoung@redhat.com>
> Cc: Kairui Song <ryncsn@gmail.com>
> Cc: Pingfan Liu <kernelfans@gmail.com>
> Cc: Andrew Morton <akpm@linux-foundation.org>
> Cc: Krzysztof Kozlowski <krzk@kernel.org>
> Cc: Rob Herring <robh@kernel.org>
> Signed-off-by: Coiby Xu <coxu@redhat.com>
> ---
> v3
> - Delete the property after reading it [Rob Herring]
>
> v2
> - Krzysztof
> - Use imperative mood for commit message
> - Add dt-schema ABI Documentation
> https://github.com/devicetree-org/dt-schema/pull/181
> - Don't print dm-crypt keys address via pr_debug
>
>
> arch/arm64/kernel/machine_kexec_file.c | 9 +++++++++
> drivers/of/fdt.c | 21 +++++++++++++++++++++
> drivers/of/kexec.c | 19 +++++++++++++++++++
> 3 files changed, 49 insertions(+)
>
> diff --git a/arch/arm64/kernel/machine_kexec_file.c b/arch/arm64/kernel/machine_kexec_file.c
> index 410060ebd86d..5f3bad8ca96d 100644
> --- a/arch/arm64/kernel/machine_kexec_file.c
> +++ b/arch/arm64/kernel/machine_kexec_file.c
> @@ -134,6 +134,15 @@ int load_other_segments(struct kimage *image,
>
> kexec_dprintk("Loaded elf core header at 0x%lx bufsz=0x%lx memsz=0x%lx\n",
> image->elf_load_addr, kbuf.bufsz, kbuf.memsz);
> +
> + ret = crash_load_dm_crypt_keys(image);
> +
> + if (ret == -ENOENT) {
> + kexec_dprintk("No dm crypt key to load\n");
> + } else if (ret) {
> + pr_err("Failed to load dm crypt keys\n");
> + goto out_err;
> + }
This looks like an unusual mixture of kexec_dprintk() and pr_err().
Stepping back a second, why do we need to print anything from the arch
code at all? It looks like crash_load_dm_crypt_keys() already prints for
the -ENOENT case so I'd be inclined just to do:
ret = crash_load_dm_crypt_keys(image);
if (ret)
goto out_err;
Will
next prev parent reply other threads:[~2026-01-26 14:36 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-01-23 8:13 [PATCH v3] arm64/kdump: pass dm-crypt keys to kdump kernel Coiby Xu
2026-01-26 14:36 ` Will Deacon [this message]
2026-01-29 10:40 ` Coiby Xu
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=aXd72PcvvFsIFXO2@willie-the-truck \
--to=will@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnaud.lefebvre@clever-cloud.com \
--cc=bhe@redhat.com \
--cc=catalin.marinas@arm.com \
--cc=coxu@redhat.com \
--cc=devicetree@vger.kernel.org \
--cc=dyoung@redhat.com \
--cc=kernelfans@gmail.com \
--cc=kexec@lists.infradead.org \
--cc=krzk@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=robh@kernel.org \
--cc=ryncsn@gmail.com \
--cc=saravanak@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.