From: Eric DeVolder <eric.devolder@oracle.com>
To: kexec@lists.infradead.org
Cc: boris.ostrovsky@oracle.com, eric.devolder@oracle.com
Subject: [PATCH v1 0/7] crashdump: Kernel handling of CPU and memory hot un/plug
Date: Thu, 20 Oct 2022 13:03:37 -0400 [thread overview]
Message-ID: <20221020170344.1962-1-eric.devolder@oracle.com> (raw)
When the kdump service is loaded, if a CPU or memory is hot
un/plugged, the crash elfcorehdr, which describes the CPUs and memory
in the system, must also be updated, else the resulting vmcore is
inaccurate (eg. missing either CPU context or memory regions).
The current solution (eg. RHEL /usr/lib/udev/rules.d/98-kexec.rules)
utilizes udev to initiate an unload-then-reload of the *entire* kdump
image (eg. kernel, initrd, boot_params, puratory and elfcorehdr) by
the userspace kexec utility. In a previous kernel patch post I have
outlined the significant performance problems related to offloading
this activity to userspace (link below, s/vmcoreinfo/elfcorehdr/).
https://lore.kernel.org/lkml/b04ed259-dc5f-7f30-6661-c26f92d9096a@oracle.com/
As such, I've been working to provide the ability for the Linux kernel
to directly modify the elfcorehdr in response to hotplug changes.
https://lore.kernel.org/lkml/20220909210509.6286-1-eric.devolder@oracle.com/
The most recent patch series is listed above, and I believe this work
to be nearing the finish line. As such, I'd like to start posting the
kexec-tools userspace changes for review in order to minimize the time
to adoption.
This kexec-tools patch series is for supporting the kexec_load
syscall only. The kernel patch series cited above makes the needed
changes to support the kexec_file_load syscall.
There are two basic obstacles/requirements for the kexec-tools to
overcome in order to support kernel hotplug rewriting of the
elfcorehdr.
First, the buffer containing the elfcorehdr must be excluded from the
purgatory checksum/digest, which is computed at load time. Otherwise
kernel run-time changes to the elfcorehdr, as a result of hot un/plug,
would result in the checksum failing (specifically in purgatory at
panic kernel boot time), and kdump capture kernel failing to start.
NOTE: The kernel specifically does *NOT* attempt to recompute the
checksum/digest as that would ultimately require patching the in-
memory purgatory image with the updated checksum. As that purgatory
image is already fully linked, it is binary blob containing no ELF
information which would allow it to be re-linked or patched. Thus
excluding the elfcorehdr from the checksum/digests avoids all these
problems.
Second, the size of the elfcorehdr buffer must be large enough
to accomodate growth of the number of CPUs and/or memory regions.
To satisfy the first requirement, this patch series introduces the
--hotplug option to indicate to kexec-tools that kexec should exclude
the elfcorehdr buffer from the purgatory checksum/digest calculation.
To satisfy the second requirement, this patch series introduces the
get_elfcorehdrsz() function to determine the size of the elfcorehdr
buffer. This routine takes into account the --hotplug and
--elfcorehdrsz options in determining the size (see "crashdump:
create get_elfcorehdrsz()" for details).
I am intentionally posting this series before the kernel changes
have been merged. I'm hoping to facilitate discussion as to how
kexec-tools wants to handle the soon-to-be new kernel feature.
Discussion items:
- It is worth noting, that deploying kexec-tools, with this series
included, on kernels that do NOT have the kernel hotplug series
cited above, is safe to do. The result of running a kernel without
hotplug elfcorehdr support with kexec-tools and the --hotplug option
simply removes the elfcorehdr buffer from the digest. This does not
prevent kdump from operating; the only risk being a slight chance of
corruption of the elfcorehdr, as it now not covered by the checksum.
Using the --elfcorehdrsz option on a kernel without hotplug
elfcorehdr support simply results in a possibly oversized buffer for
the elfcorehdr, there is no harm in that.
- While I currently have the --hotplug as an option, the option could
be eliminated (or reversed polarity) it would be safe to *always*
omit the elfcorehdr from the checksum/digest for purgatory.
If this were the case, then distros would not have to make any
changes to kdump scripts to pass the --hotplug option. Then, when
their kernel does include the kernel patch series cited above,
kdump and hotplug would "just work".
- I'm unsure if these options should be kept as common/global
kexec options, or moved to arch options.
- I'm only showing x86 support (and testing) at this time, but
it would be straight forward to provide similar support for the
other architectures in a future patch revision.
Thanks!
eric
---
v1: 20oct2022
- Initial patch series
---
Eric DeVolder (7):
crashdump: introduce the --hotplug option
crashdump: exclude elfcorehdr segment from digest for hotplug
crashdump/x86: identify elfcorehdr segment for hotplug
kexec: create get_nr_cpus()
crashdump: introduce --elfcorehdrsz option
crashdump: create get_elfcorehdrsz()
crashdump/x86: utilize get_elfcorehdrsz()
include/elf.h | 2 ++
kexec/arch/i386/crashdump-x86.c | 9 ++++++++
kexec/crashdump-elf.c | 6 +-----
kexec/crashdump.c | 33 +++++++++++++++++++++++++++++
kexec/crashdump.h | 5 ++++-
kexec/kexec-xen.h | 1 +
kexec/kexec.c | 37 +++++++++++++++++++++++++++++++++
kexec/kexec.h | 13 +++++++++++-
8 files changed, 99 insertions(+), 7 deletions(-)
--
2.31.1
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
next reply other threads:[~2022-10-20 17:04 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-20 17:03 Eric DeVolder [this message]
2022-10-20 17:03 ` [PATCH v1 1/7] crashdump: introduce the --hotplug option Eric DeVolder
2022-10-20 17:03 ` [PATCH v1 2/7] crashdump: exclude elfcorehdr segment from digest for hotplug Eric DeVolder
2022-10-20 17:03 ` [PATCH v1 3/7] crashdump/x86: identify elfcorehdr segment " Eric DeVolder
2022-10-20 17:03 ` [PATCH v1 4/7] kexec: create get_nr_cpus() Eric DeVolder
2022-10-20 17:03 ` [PATCH v1 5/7] crashdump: introduce --elfcorehdrsz option Eric DeVolder
2022-10-20 17:03 ` [PATCH v1 6/7] crashdump: create get_elfcorehdrsz() Eric DeVolder
2022-10-20 17:03 ` [PATCH v1 7/7] crashdump/x86: utilize get_elfcorehdrsz() Eric DeVolder
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=20221020170344.1962-1-eric.devolder@oracle.com \
--to=eric.devolder@oracle.com \
--cc=boris.ostrovsky@oracle.com \
--cc=kexec@lists.infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox