crash_dump/dm-crypt: don't print in arch-specific code

Patch series "kdump: Enable LUKS-encrypted dump target support in ARM64
and PowerPC", v5.

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 and PowerPC, we need to add a 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.

This patch (of 3):

When the vmcore dumping target is not a LUKS-encrypted target, it's
expected that there is no dm-crypt key thus no need to return -ENOENT.
Also print more logs in crash_load_dm_crypt_keys.  The benefit is
arch-specific code can be more succinct.

Link: https://lkml.kernel.org/r/20260225060347.718905-1-coxu@redhat.com
Link: https://lkml.kernel.org/r/20260225060347.718905-2-coxu@redhat.com
Link: https://lore.kernel.org/all/20250502011246.99238-1-coxu@redhat.com/
Link: https://github.com/devicetree-org/dt-schema/pull/181
Signed-off-by: Coiby Xu <coxu@redhat.com>
Suggested-by: Will Deacon <will@kernel.org>
Acked-by: Baoquan He <bhe@redhat.com>
Cc: Arnaud Lefebvre <arnaud.lefebvre@clever-cloud.com>
Cc: Christophe Leroy (CS GROUP) <chleroy@kernel.org>
Cc: Dave Young <dyoung@redhat.com>
Cc: Kairui Song <ryncsn@gmail.com>
Cc: Krzysztof Kozlowski <krzk@kernel.org>
Cc: Pingfan Liu <kernelfans@gmail.com>
Cc: Rob Herring <robh@kernel.org>
Cc: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: Thomas Staudt <tstaudt@de.ibm.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>

diff --git a/arch/x86/kernel/kexec-bzimage64.c b/arch/x86/kernel/kexec-bzimage64.c
index 5630c7dca1f3d27309f14175e9636dd90357dbae..7e980ea49d8d62e878e20fd5b8c1548a1e86442a 100644 (file)
--- a/arch/x86/kernel/kexec-bzimage64.c
+++ b/arch/x86/kernel/kexec-bzimage64.c
@@ -525,12 +525,8 @@ static void *bzImage64_load(struct kimage *image, char *kernel,
                if (ret)
                        return ERR_PTR(ret);
                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");
+               if (ret)
                        return ERR_PTR(ret);
-               }
                if (image->dm_crypt_keys_addr &&
                    cmdline_len + MAX_ELFCOREHDR_STR_LEN + MAX_DMCRYPTKEYS_STR_LEN >
                            header->cmdline_size) {

diff --git a/kernel/crash_dump_dm_crypt.c b/kernel/crash_dump_dm_crypt.c
index 8638b821ce588b536d64e4a4088a8f65300ec798..cb875ddb6ba68b6de8b39d5d5d9d3593ad0d8ffd 100644 (file)
--- a/kernel/crash_dump_dm_crypt.c
+++ b/kernel/crash_dump_dm_crypt.c
@@ -415,14 +415,16 @@ int crash_load_dm_crypt_keys(struct kimage *image)
 
        if (key_count <= 0) {
                kexec_dprintk("No dm-crypt keys\n");
-               return -ENOENT;
+               return 0;
        }
 
        if (!is_dm_key_reused) {
                image->dm_crypt_keys_addr = 0;
                r = build_keys_header();
-               if (r)
+               if (r) {
+                       pr_err("Failed to build dm-crypt keys header, ret=%d\n", r);
                        return r;
+               }
        }
 
        kbuf.buffer = keys_header;
@@ -433,6 +435,7 @@ int crash_load_dm_crypt_keys(struct kimage *image)
        kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
        r = kexec_add_buffer(&kbuf);
        if (r) {
+               pr_err("Failed to call kexec_add_buffer, ret=%d\n", r);
                kvfree((void *)kbuf.buffer);
                return r;
        }