Re: [PATCH v14 3/7] crash: add generic infrastructure for crash hotplug support
On 12/07/22 at 04:56pm, Borislav Petkov wrote: > On Wed, Dec 07, 2022 at 09:57:48PM +0800, Baoquan He wrote: > > I thought we usually need to introduce the kernel config option, then > > add code related to it, so that is a wrong idea. > > It depends: sometimes it is prudent to add the code behind an ifdeffery > first but have it not being buildable so that you don't have to deal > with build breakages but rather concentrate on adding the facilities > first. > > And you add the Kconfig item only in the end where everything is in > place and it should build properly then. I see. Now it's pretty clear to us. Thanks a lot. > > > It would be helpful to tell this somewhere in document. > > Feel free. I mean, it is pretty obvious but if it helps, it wouldn't hurt. OK, at least people tracking this thread got this now. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v14 3/7] crash: add generic infrastructure for crash hotplug support
On Wed, Dec 07, 2022 at 09:57:48PM +0800, Baoquan He wrote: > I thought we usually need to introduce the kernel config option, then > add code related to it, so that is a wrong idea. It depends: sometimes it is prudent to add the code behind an ifdeffery first but have it not being buildable so that you don't have to deal with build breakages but rather concentrate on adding the facilities first. And you add the Kconfig item only in the end where everything is in place and it should build properly then. > It would be helpful to tell this somewhere in document. Feel free. I mean, it is pretty obvious but if it helps, it wouldn't hurt. -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
[ANNOUNCE] kexec-tools 2.0.26-rc1
Hi all, I am happy to announce the release of kexec-tools 2.0.26-rc1. This is an incremental feature pre-release. So long as no serious problems arise I intend to release kexec-tools 2.0.26 in a weeks time. Testing of 2.0.26-rc1 would be greatly appreciated. I do not have any outstanding changes for 2.0.26 at this time. And I would like to only accept bug fixes at this time and take features patches once 2.0.26 has been released. The pre-release can be downloaded from kernel.org: https://kernel.org/pub/linux/utils/kernel/kexec/kexec-tools-2.0.26-rc1.tar.xz https://kernel.org/pub/linux/utils/kernel/kexec/ I have also tagged it in git: https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git Thanks to everyone who has contributed to kexec. For reference the changes since v2.0.25 are: ffb186b83420 kexec-tools 2.0.26-rc1 b9de05184816 m68k: pass rng seed via BI_RNG_SEED b0381b817910 workflow: update to checkout@v3 834be38cc044 LoongArch: Remove redundant cmdline parameters when using --reuse-cmdline option 84138f41efd5 LoongArch: Add purgatory framework code 615b6757dcab LoongArch: PE format image loading support 1c8bf2dc0127 LoongArch: Add kexec/kdump support dceb1d8926e6 config: Add LoongArch architecture support in config.guess and config.sub files 6b6187f546f0 ppc64: remove rma_top limit bc38df5e8e24 kexec-tools 2.0.25.git ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V5 0/2] Support VMCOREINFO export for RISCV64
On Wed, Dec 07, 2022 at 11:34:57AM +0800, Guo Ren wrote: > On Wed, Dec 7, 2022 at 7:05 AM Conor Dooley wrote: > > > > Hey Palmer, Xianting, > > > > On Fri, Dec 02, 2022 at 04:49:39PM -0800, Palmer Dabbelt wrote: > > > On Wed, 26 Oct 2022 22:42:06 +0800, Xianting Tian wrote: > > > > As disscussed in below patch set, the patch of 'describe VMCOREINFO > > > > export in Documentation' > > > > need to update according to Bagas's comments. > > > > https://lore.kernel.org/linux-riscv/22aaf52e-8cc8-4d11-99cb-88de4d113...@kernel.org/ > > > > > > > > As others patches in above patch set already applied, so this patch set > > > > only contains below two > > > > patches. > > > > > > > > [...] > > > > > > Applied, thanks! > > > > > > [1/2] RISC-V: Add arch_crash_save_vmcoreinfo support > > > https://git.kernel.org/palmer/c/649d6b1019a2 > > > > So this patch seems to be causing issues for the nommu build: > > https://lore.kernel.org/oe-kbuild-all/202212062250.tr0othcz-...@intel.com/ > > > > I had a bit of a poke at trying to see if there were some headers we > > could pull in before actually checking the .config only to see: > > # CONFIG_MMU is not set > > > > Do we have to wrap the whole thing in a `#ifdef CONFIG_MMU` to fix > > compilation here? > The problem does not belong to the patch. > > Could I send a fixup patch? like this? That seems like a sane dependancy, but did you build that config? This doesn't fix the problem for me :/ > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index ef8d66de5f38..d8c07999426c 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -512,6 +512,7 @@ config ARCH_HAS_KEXEC_PURGATORY > > config CRASH_DUMP > bool "Build kdump crash kernel" > + depends on KEXEC > help > Generate crash dump after being started by kexec. This should > be normally only set in special crash dump kernels which are > > > > > Thanks, > > Conor. > > > > > -- > Best Regards > Guo Ren signature.asc Description: PGP signature ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V5 0/2] Support VMCOREINFO export for RISCV64
Hey Palmer, Xianting, On Fri, Dec 02, 2022 at 04:49:39PM -0800, Palmer Dabbelt wrote: > On Wed, 26 Oct 2022 22:42:06 +0800, Xianting Tian wrote: > > As disscussed in below patch set, the patch of 'describe VMCOREINFO export > > in Documentation' > > need to update according to Bagas's comments. > > https://lore.kernel.org/linux-riscv/22aaf52e-8cc8-4d11-99cb-88de4d113...@kernel.org/ > > > > As others patches in above patch set already applied, so this patch set > > only contains below two > > patches. > > > > [...] > > Applied, thanks! > > [1/2] RISC-V: Add arch_crash_save_vmcoreinfo support > https://git.kernel.org/palmer/c/649d6b1019a2 So this patch seems to be causing issues for the nommu build: https://lore.kernel.org/oe-kbuild-all/202212062250.tr0othcz-...@intel.com/ I had a bit of a poke at trying to see if there were some headers we could pull in before actually checking the .config only to see: # CONFIG_MMU is not set Do we have to wrap the whole thing in a `#ifdef CONFIG_MMU` to fix compilation here? Thanks, Conor. signature.asc Description: PGP signature ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v14 3/7] crash: add generic infrastructure for crash hotplug support
On 12/07/22 at 01:42pm, Borislav Petkov wrote: > On Wed, Dec 07, 2022 at 08:36:13PM +0800, Baoquan He wrote: > > Below is my last reply to Eric about my thinking on this. > > Yes, I saw that. > > So think about it: if a CONFIG_ item is not present, what does that mean > for the code which is enclosed around it? Ignored by compiler. I thought we usually need to introduce the kernel config option, then add code related to it, so that is a wrong idea. It would be helpful to tell this somewhere in document. ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v14 3/7] crash: add generic infrastructure for crash hotplug support
On Wed, Dec 07, 2022 at 08:36:13PM +0800, Baoquan He wrote: > Below is my last reply to Eric about my thinking on this. Yes, I saw that. So think about it: if a CONFIG_ item is not present, what does that mean for the code which is enclosed around it? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v14 3/7] crash: add generic infrastructure for crash hotplug support
On 12/07/22 at 11:00am, Borislav Petkov wrote: > On Fri, Nov 25, 2022 at 11:26:53AM +0800, Baoquan He wrote: > > This kernel config CRASH_HOTPLUG is added in patch 7, but we have used > > it in the previous patch, not sure if this is acceptable. > > Why would it not be acceptable? Below is my last reply to Eric about my thinking on this. That would be great if it's a normal situation when adding Kconfig item, I am happy to learn this if it's confirmed normal. = Hmm, since it's bisect-able, seems doesn't break rule. I could be too sensitive. Do we have a precendent like this, to strengthen our confidence? If no concern from other people, it's also fine to me. = Thanks Baoquan ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v14 7/7] x86/crash: add x86 crash hotplug support
On Wed, Nov 16, 2022 at 04:46:43PM -0500, Eric DeVolder wrote:
> When CPU or memory is hot un/plugged, the crash elfcorehdr, which
> describes the CPUs and memory in the system, must also be updated.
>
> A new elfcorehdr is generated from the available CPUs and memory
> into a buffer, and then installed over the top of the existing
> elfcorehdr. The segment containing the elfcorehdr is identified
> at run time in crash_core:handle_hotplug_event(), which works for
> both the kexec_load() and kexec_file_load() syscalls.
>
> In the patch 'kexec: exclude elfcorehdr from the segment digest'
> the need to update purgatory due to the change in elfcorehdr was
> eliminated. As a result, no changes to purgatory or boot_params
> (as the elfcorehdr= kernel command line parameter pointer
> remains unchanged and correct) are needed, just elfcorehdr.
>
> To accommodate a growing number of resources via hotplug, the
> elfcorehdr segment must be sufficiently large enough to accommodate
> changes, see the CRASH_MAX_MEMORY_RANGES description.
>
> Signed-off-by: Eric DeVolder
> ---
> arch/x86/Kconfig | 9 +++
> arch/x86/include/asm/kexec.h | 15 +
> arch/x86/kernel/crash.c | 106 ++-
> 3 files changed, 127 insertions(+), 3 deletions(-)
Some quick cleanups ontop, there's potential for more:
---
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index ffee99046942..486509030d3a 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -2091,13 +2091,16 @@ config CRASH_DUMP
For more details see Documentation/admin-guide/kdump/kdump.rst
config CRASH_HOTPLUG
- bool "kernel updates of crash elfcorehdr"
+ bool "Update the crash elfcorehdr on system configuration changes"
default n
depends on CRASH_DUMP && (HOTPLUG_CPU || MEMORY_HOTPLUG)
help
- Enable the kernel to directly update the crash elfcorehdr (which
- contains the list of CPUs and memory regions to be dumped upon
- a crash) in response to hot plug/unplug of CPUs or memory.
+ Enable direct updates to the crash elfcorehdr (which contains
+ the list of CPUs and memory regions to be dumped upon a crash)
+ in response to hot plug/unplug of CPUs or memory. This is a much
+ more advanced approach than userspace attempting that.
+
+ If unsure, say Y.
config KEXEC_JUMP
bool "kexec jump"
diff --git a/arch/x86/kernel/crash.c b/arch/x86/kernel/crash.c
index d2238bcf8106..d26f208e582e 100644
--- a/arch/x86/kernel/crash.c
+++ b/arch/x86/kernel/crash.c
@@ -413,25 +413,32 @@ int crash_load_segments(struct kimage *image)
image->elf_headers_sz = kbuf.bufsz;
kbuf.memsz = kbuf.bufsz;
-#ifdef CONFIG_CRASH_HOTPLUG
- /* Ensure elfcorehdr segment large enough for hotplug changes */
- unsigned long pnum = 2; /* VMCOREINFO and kernel_map */
-
- if (IS_ENABLED(CONFIG_HOTPLUG_CPU))
- pnum += CONFIG_NR_CPUS_DEFAULT;
- if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
- pnum += CRASH_MAX_MEMORY_RANGES;
- if (pnum < (unsigned long)PN_XNUM) {
- kbuf.memsz = pnum * sizeof(Elf64_Phdr);
- kbuf.memsz += sizeof(Elf64_Ehdr);
- image->elfcorehdr_index = image->nr_segments;
- image->elfcorehdr_index_valid = true;
- /* Mark as usable to crash kernel, else crash kernel fails on
boot */
- image->elf_headers_sz = kbuf.memsz;
- } else {
- pr_err("number of Phdrs %lu exceeds max\n", pnum);
+ if (IS_ENABLED(CONFIG_CRASH_HOTPLUG)) {
+ /*
+* Ensure the elfcorehdr segment large enough for hotplug
changes.
+* Start with VMCOREINFO and kernel_map:
+*/
+ unsigned long pnum = 2;
+
+ if (IS_ENABLED(CONFIG_HOTPLUG_CPU))
+ pnum += CONFIG_NR_CPUS_DEFAULT;
+
+ if (IS_ENABLED(CONFIG_MEMORY_HOTPLUG))
+ pnum += CRASH_MAX_MEMORY_RANGES;
+
+ if (pnum < (unsigned long)PN_XNUM) {
+ kbuf.memsz = pnum * sizeof(Elf64_Phdr);
+ kbuf.memsz += sizeof(Elf64_Ehdr);
+
+ image->elfcorehdr_index = image->nr_segments;
+ image->elfcorehdr_index_valid = true;
+
+ /* Mark as usable to crash kernel, else crash kernel
fails on boot */
+ image->elf_headers_sz = kbuf.memsz;
+ } else {
+ pr_err("number of Phdrs %lu exceeds max\n", pnum);
+ }
}
-#endif
kbuf.buf_align = ELF_CORE_HEADER_ALIGN;
kbuf.mem = KEXEC_BUF_MEM_UNKNOWN;
@@ -463,10 +470,9 @@ int crash_load_segments(struct kimage *image)
*/
void arch_crash_handle_hotplug_event(struct kimage *image)
{
+ void *elfbuf, *old_elfcorehdr;
unsigned long
Re: [PATCH v14 3/7] crash: add generic infrastructure for crash hotplug support
On Wed, Nov 16, 2022 at 04:46:39PM -0500, Eric DeVolder wrote:
> +#ifndef arch_map_crash_pages
> +/*
> + * NOTE: The addresses and sizes passed to this routine have
> + * already been fully aligned on page boundaries. There is no
> + * need for massaging the address or size.
> + */
> +static inline void *arch_map_crash_pages(unsigned long paddr,
> + unsigned long size)
> +{
> + if (size > 0)
> + return kmap_local_page(pfn_to_page(paddr >> PAGE_SHIFT));
> + else
> + return NULL;
> +}
> +#endif
> +
> +#ifndef arch_unmap_crash_pages
> +static inline void arch_unmap_crash_pages(void *ptr)
> +{
> + if (ptr)
> + kunmap_local(ptr);
> +}
> +#endif
Why is that function still here and why aren't you calling
kmap_local_page() simply?
--
Regards/Gruss,
Boris.
https://people.kernel.org/tglx/notes-about-netiquette
___
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH v14 3/7] crash: add generic infrastructure for crash hotplug support
On Fri, Nov 25, 2022 at 11:26:53AM +0800, Baoquan He wrote: > This kernel config CRASH_HOTPLUG is added in patch 7, but we have used > it in the previous patch, not sure if this is acceptable. Why would it not be acceptable? -- Regards/Gruss, Boris. https://people.kernel.org/tglx/notes-about-netiquette ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
Re: [PATCH V5 0/2] Support VMCOREINFO export for RISCV64
On Wed, Dec 7, 2022 at 4:08 PM Conor Dooley wrote: > > On Wed, Dec 07, 2022 at 11:34:57AM +0800, Guo Ren wrote: > > On Wed, Dec 7, 2022 at 7:05 AM Conor Dooley wrote: > > > > > > Hey Palmer, Xianting, > > > > > > On Fri, Dec 02, 2022 at 04:49:39PM -0800, Palmer Dabbelt wrote: > > > > On Wed, 26 Oct 2022 22:42:06 +0800, Xianting Tian wrote: > > > > > As disscussed in below patch set, the patch of 'describe VMCOREINFO > > > > > export in Documentation' > > > > > need to update according to Bagas's comments. > > > > > https://lore.kernel.org/linux-riscv/22aaf52e-8cc8-4d11-99cb-88de4d113...@kernel.org/ > > > > > > > > > > As others patches in above patch set already applied, so this patch > > > > > set only contains below two > > > > > patches. > > > > > > > > > > [...] > > > > > > > > Applied, thanks! > > > > > > > > [1/2] RISC-V: Add arch_crash_save_vmcoreinfo support > > > > https://git.kernel.org/palmer/c/649d6b1019a2 > > > > > > So this patch seems to be causing issues for the nommu build: > > > https://lore.kernel.org/oe-kbuild-all/202212062250.tr0othcz-...@intel.com/ > > > > > > I had a bit of a poke at trying to see if there were some headers we > > > could pull in before actually checking the .config only to see: > > > # CONFIG_MMU is not set > > > > > > Do we have to wrap the whole thing in a `#ifdef CONFIG_MMU` to fix > > > compilation here? > > The problem does not belong to the patch. > > > > Could I send a fixup patch? like this? > > That seems like a sane dependancy, but did you build that config? > This doesn't fix the problem for me :/ Sorry, It's the wrong fixup. Here is the new version, and tested. Thx for the report. https://lore.kernel.org/linux-riscv/20221207091112.2258674-1-guo...@kernel.org/ > > > > > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > > index ef8d66de5f38..d8c07999426c 100644 > > --- a/arch/riscv/Kconfig > > +++ b/arch/riscv/Kconfig > > @@ -512,6 +512,7 @@ config ARCH_HAS_KEXEC_PURGATORY > > > > config CRASH_DUMP > > bool "Build kdump crash kernel" > > + depends on KEXEC > > help > > Generate crash dump after being started by kexec. This should > > be normally only set in special crash dump kernels which are > > > > > > > > Thanks, > > > Conor. > > > > > > > > > -- > > Best Regards > > Guo Ren -- Best Regards Guo Ren ___ kexec mailing list kexec@lists.infradead.org http://lists.infradead.org/mailman/listinfo/kexec
