From: Coiby Xu <coiby.xu@gmail.com>
To: Sourabh Jain <sourabhjain@linux.ibm.com>
Cc: kexec@lists.infradead.org, stable@vger.kernel.org,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <bhe@redhat.com>, Vivek Goyal <vgoyal@redhat.com>,
Dave Young <dyoung@redhat.com>,
open list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] crash_dump: Fix potential double free and UAF of keys_header
Date: Sat, 2 May 2026 07:54:05 +0800 [thread overview]
Message-ID: <afU8HsdlkQo0oM00@Rk> (raw)
In-Reply-To: <401693ba-1455-4b45-8596-b81625f01201@linux.ibm.com>
On Tue, Apr 07, 2026 at 03:29:18PM +0530, Sourabh Jain wrote:
>
[...]
>>>As per kdump.rst, restore was introduced to handle CPU and
>>>memory hotplug cases. Is it needed when there is no in-kernel
>>>update to the kdump image on CPU or memory hotplug events?
>>>
>>>But in that case, we rely on a udev rule to reload the kdump image
>>>again.
>>>
>>>I am confused about when exactly we need to restore.
>>
>>To clarify, reuse other than restore is needed for non in-kernel update
>>when handing CPU/memory hotplugging. Yes, a udev rule is also needed in
>>this case.
>
>Below commit explains how the reuse is utilized:
>
>commit 9ebfa8dcaea77a8ef02d0f9478717a138b0ad828
>Author: Coiby Xu <coxu@redhat.com>
>Date: Fri May 2 09:12:38 2025 +0800
>
> crash_dump: reuse saved dm crypt keys for CPU/memory hot-plugging
>
>It got it now. This is helpful when kdump needs to be reloaded due to
>CPU/memory hotplug events using the kexec_file_load system call,
>but only when CONFIG_CRASH_HOTPLUG is not enabled.
>
>IIUC this feature is not support on crash image loaded using
>kexec_load syscall, right?
Glad you've figured it out! Yes, you are correct. If
CONFIG_CRASH_HOTPLUG is enabled, there is no need for configfs/reuse. In
v2, I've improved the doc and also added a patch to prevented using this
API when CONFIG_CRASH_HOTPLUG is enabled.
--
Best regards,
Coiby
next prev parent reply other threads:[~2026-05-02 1:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-03 10:01 [PATCH] crash_dump: Fix potential double free and UAF of keys_header Coiby Xu
2026-04-03 14:18 ` Sourabh Jain
2026-04-07 0:44 ` Coiby Xu
2026-04-07 9:59 ` Sourabh Jain
2026-05-01 23:54 ` Coiby Xu [this message]
2026-05-01 23:49 ` 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=afU8HsdlkQo0oM00@Rk \
--to=coiby.xu@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=bhe@redhat.com \
--cc=dyoung@redhat.com \
--cc=kexec@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sourabhjain@linux.ibm.com \
--cc=stable@vger.kernel.org \
--cc=vgoyal@redhat.com \
/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.