| Message ID | 20240823125156.104775-1-dave@vasilevsky.ca (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | crash: Default to CRASH_DUMP=n when support for it is unlikely | expand |
Hi Dave, On Fri, Aug 23, 2024 at 2:54 PM Dave Vasilevsky <dave@vasilevsky.ca> wrote: > Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using > Open Firmware. On these machines, the kernel refuses to boot > from non-zero PHYSICAL_START, which occurs when CRASH_DUMP is on. > > Since most PPC_BOOK3S_32 machines boot via Open Firmware, it should > default to off for them. Users booting via some other mechanism > can still turn it on explicitly. > > Also defaults to CRASH_DUMP=n on sh. > > Signed-off-by: Dave Vasilevsky <dave@vasilevsky.ca> > Reported-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> > Closes: https://lists.debian.org/debian-powerpc/2024/07/msg00001.html > Fixes: 75bc255a7444 ("crash: clean up kdump related config items") Thanks for your patch! > --- a/kernel/Kconfig.kexec > +++ b/kernel/Kconfig.kexec > @@ -97,7 +97,7 @@ config KEXEC_JUMP > > config CRASH_DUMP > bool "kernel crash dumps" > - default y > + default ARCH_DEFAULT_CRASH_DUMP > depends on ARCH_SUPPORTS_CRASH_DUMP > depends on KEXEC_CORE > select VMCORE_INFO IMHO CRASH_DUMP should just default to n, like most kernel options, as it enables non-trivial extra functionality: the kernel source tree has more than 100 locations that check if CONFIG_CRASH_DUMP is enabled. Letting it default to enabled also conflicts with the spirit of the help text for the symbol: Generate crash dump after being started by kexec. This should be normally only set in special crash dump kernels ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ which are loaded in the main kernel with kexec-tools into a specially reserved region and then later executed after a crash by kdump/kexec. The crash dump kernel must be compiled to a memory address not used by the main kernel or BIOS using PHYSICAL_START, or it must be built as a relocatable image (CONFIG_RELOCATABLE=y). For more details see Documentation/admin-guide/kdump/kdump.rst For s390, this option also enables zfcpdump. See also <file:Documentation/arch/s390/zfcpdump.rst> What is so special about CRASH_DUMP, that it should be enabled by default? Gr{oetje,eeting}s, Geert
Hi Geert, On Fri, 2024-08-23 at 15:13 +0200, Geert Uytterhoeven wrote: > IMHO CRASH_DUMP should just default to n, like most kernel options, as > it enables non-trivial extra functionality: the kernel source tree has > more than 100 locations that check if CONFIG_CRASH_DUMP is enabled. I guess we should then revert that part of Baoquan's original patch. > What is so special about CRASH_DUMP, that it should be enabled by > default? Let's ask Baoquan who made the original change to enable CRASH_DUMP by default. Adrian
Geert Uytterhoeven <geert@linux-m68k.org> writes: > Hi Dave, > > On Fri, Aug 23, 2024 at 2:54 PM Dave Vasilevsky <dave@vasilevsky.ca> wrote: >> Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using >> Open Firmware. On these machines, the kernel refuses to boot >> from non-zero PHYSICAL_START, which occurs when CRASH_DUMP is on. >> >> Since most PPC_BOOK3S_32 machines boot via Open Firmware, it should >> default to off for them. Users booting via some other mechanism >> can still turn it on explicitly. >> >> Also defaults to CRASH_DUMP=n on sh. >> >> Signed-off-by: Dave Vasilevsky <dave@vasilevsky.ca> >> Reported-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> >> Closes: https://lists.debian.org/debian-powerpc/2024/07/msg00001.html >> Fixes: 75bc255a7444 ("crash: clean up kdump related config items") > > Thanks for your patch! > >> --- a/kernel/Kconfig.kexec >> +++ b/kernel/Kconfig.kexec >> @@ -97,7 +97,7 @@ config KEXEC_JUMP >> >> config CRASH_DUMP >> bool "kernel crash dumps" >> - default y >> + default ARCH_DEFAULT_CRASH_DUMP >> depends on ARCH_SUPPORTS_CRASH_DUMP >> depends on KEXEC_CORE >> select VMCORE_INFO > > IMHO CRASH_DUMP should just default to n, like most kernel options, as > it enables non-trivial extra functionality: the kernel source tree has > more than 100 locations that check if CONFIG_CRASH_DUMP is enabled. > > Letting it default to enabled also conflicts with the spirit of the > help text for the symbol: > > Generate crash dump after being started by kexec. > This should be normally only set in special crash dump kernels > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > which are loaded in the main kernel with kexec-tools into > a specially reserved region and then later executed after > a crash by kdump/kexec. The crash dump kernel must be compiled > to a memory address not used by the main kernel or BIOS using > PHYSICAL_START, or it must be built as a relocatable image > (CONFIG_RELOCATABLE=y). > For more details see Documentation/admin-guide/kdump/kdump.rst > > For s390, this option also enables zfcpdump. > See also <file:Documentation/arch/s390/zfcpdump.rst> > > What is so special about CRASH_DUMP, that it should be enabled by > default? The reality is that essentially all distros enable it. Because they don't want to manage separate kernel / crash-kernel packages. So IMHO having it enabled by default in upstream does make sense, because it more closely matches what distros/users actually run. cheers
Hi Michael, On Mon, 2024-08-26 at 12:02 +1000, Michael Ellerman wrote: > > What is so special about CRASH_DUMP, that it should be enabled by > > default? > > The reality is that essentially all distros enable it. Because they > don't want to manage separate kernel / crash-kernel packages. > > So IMHO having it enabled by default in upstream does make sense, > because it more closely matches what distros/users actually run. Well, at least Debian did not enable it by default as otherwise we wouldn't have noticed this change downstream. Adrian
On 2024-08-26 01:38, John Paul Adrian Glaubitz wrote: > On Mon, 2024-08-26 at 12:02 +1000, Michael Ellerman wrote: >> So IMHO having it enabled by default in upstream does make sense, >> because it more closely matches what distros/users actually run. > > Well, at least Debian did not enable it by default as otherwise we wouldn't > have noticed this change downstream. Debian does enable it explicitly on some supported architectures, but not all: https://salsa.debian.org/search?group_id=2107&nav_source=navbar&project_id=18670&repository_ref=master&scope=blobs&search=path%3Aconfig+CRASH_DUMP&search_code=true By my count, 6.9's new default affected mips, powerpc (32-bit), riscv, and sh in Debian. -Dave
On 08/23/24 at 08:16pm, John Paul Adrian Glaubitz wrote: > Hi Geert, > > On Fri, 2024-08-23 at 15:13 +0200, Geert Uytterhoeven wrote: > > IMHO CRASH_DUMP should just default to n, like most kernel options, as > > it enables non-trivial extra functionality: the kernel source tree has > > more than 100 locations that check if CONFIG_CRASH_DUMP is enabled. > > I guess we should then revert that part of Baoquan's original patch. > > > What is so special about CRASH_DUMP, that it should be enabled by > > default? > > Let's ask Baoquan who made the original change to enable CRASH_DUMP by default. Sorry for late reply. It's me who enabled it by default when I clean up the messy Kconfig items related to kexec/kdump. Before the clean up, CONFIG_CRASH_DUMP only controlled a very small file including sevearl functions and macro definitions. But kernel codes took CRASH_DUMP as switch of kdump. About why it's enabled by default, as Michael has explained in another thread, distros usualy needs to enable it by default because vmcore dumping is a very important feature on servers, even guest instances. Even though kdump codes are enabled to built in, not providing crashkernel= value won't make vmcore dumping take effect, it won't cost system resources in that case. Thanks Baoquan
On Tue, 2024-08-27 at 14:22 +0800, Baoquan He wrote: > About why it's enabled by default, as Michael has explained in another > thread, distros usualy needs to enable it by default because vmcore > dumping is a very important feature on servers, even guest instances. > Even though kdump codes are enabled to built in, not providing > crashkernel= value won't make vmcore dumping take effect, it won't cost > system resources in that case. OK, thanks for the explanation. But as we have found out in the mean time, the assumption was wrong to enable it by default for all architectures as some architectures cannot boot a crash dump kernel with their default bootloader but only through kexec. Can we have a follow-up patch to disable crash dump kernels where they're not needed? I mean, not every platform supported by Linux is obviously a x86-based or POWER-based server. Adrian
On 08/27/24 at 08:37am, John Paul Adrian Glaubitz wrote: > On Tue, 2024-08-27 at 14:22 +0800, Baoquan He wrote: > > About why it's enabled by default, as Michael has explained in another > > thread, distros usualy needs to enable it by default because vmcore > > dumping is a very important feature on servers, even guest instances. > > Even though kdump codes are enabled to built in, not providing > > crashkernel= value won't make vmcore dumping take effect, it won't cost > > system resources in that case. > > OK, thanks for the explanation. But as we have found out in the mean time, > the assumption was wrong to enable it by default for all architectures as > some architectures cannot boot a crash dump kernel with their default bootloader > but only through kexec. > > Can we have a follow-up patch to disable crash dump kernels where they're > not needed? I mean, not every platform supported by Linux is obviously a > x86-based or POWER-based server. Yes, while isn't Dave's patch a good one to fix it? In Dave's patch, the default enabling of CRASH_DUMP has been taken off, change to rely on ARCH_DEFAULT_CRASH_DUMP provided by each arch. config CRASH_DUMP bool "kernel crash dumps" - default y + default ARCH_DEFAULT_CRASH_DUMP
Hi Dave, On 08/23/24 at 08:51am, Dave Vasilevsky wrote: ......snip.. > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > index 1aa3c4a0c5b2..b04cfa23378c 100644 > --- a/arch/sh/Kconfig > +++ b/arch/sh/Kconfig > @@ -549,6 +549,9 @@ config ARCH_SUPPORTS_KEXEC > config ARCH_SUPPORTS_CRASH_DUMP > def_bool BROKEN_ON_SMP > > +config ARCH_DEFAULT_CRASH_DUMP > + def_bool n If we don't add ARCH_DEFAULT_CRASH_DUMP at all in sh arch, the CRASH_DUMP will be off by default according to the below new definition of CRASH_DUMP? Thanks Baoquan > + > config ARCH_SUPPORTS_KEXEC_JUMP > def_bool y > ...... > diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec > index 6c34e63c88ff..4d111f871951 100644 > --- a/kernel/Kconfig.kexec > +++ b/kernel/Kconfig.kexec > @@ -97,7 +97,7 @@ config KEXEC_JUMP > > config CRASH_DUMP > bool "kernel crash dumps" > - default y > + default ARCH_DEFAULT_CRASH_DUMP > depends on ARCH_SUPPORTS_CRASH_DUMP > depends on KEXEC_CORE > select VMCORE_INFO > -- > 2.34.1 >
On 2024-08-29 23:15, Baoquan He wrote: >> +config ARCH_DEFAULT_CRASH_DUMP >> + def_bool n > > If we don't add ARCH_DEFAULT_CRASH_DUMP at all in sh arch, the > CRASH_DUMP will be off by default according to the below new definition > of CRASH_DUMP? Yes, that's true. But if we don't add it at all in sh arch, it looks confusing in the search feature of menuconfig: > Symbol: ARCH_DEFAULT_CRASH_DUMP [=ARCH_DEFAULT_CRASH_DUMP] > Type : unknown So I thought it was better to explicitly set it to 'n'. What do you think? -Dave
On 08/29/24 at 11:37pm, Dave Vasilevsky wrote: > On 2024-08-29 23:15, Baoquan He wrote: > >> +config ARCH_DEFAULT_CRASH_DUMP > >> + def_bool n > > > > If we don't add ARCH_DEFAULT_CRASH_DUMP at all in sh arch, the > > CRASH_DUMP will be off by default according to the below new definition > > of CRASH_DUMP? > > Yes, that's true. But if we don't add it at all in sh arch, it looks confusing > in the search feature of menuconfig: > > > Symbol: ARCH_DEFAULT_CRASH_DUMP [=ARCH_DEFAULT_CRASH_DUMP] > > Type : unknown > > So I thought it was better to explicitly set it to 'n'. What do you think? If so, better adding it. Thanks.
On 08/23/24 at 08:51am, Dave Vasilevsky wrote: > Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using > Open Firmware. On these machines, the kernel refuses to boot > from non-zero PHYSICAL_START, which occurs when CRASH_DUMP is on. > > Since most PPC_BOOK3S_32 machines boot via Open Firmware, it should > default to off for them. Users booting via some other mechanism > can still turn it on explicitly. > > Also defaults to CRASH_DUMP=n on sh. The overrall looks good to me except of the CRASH_DUMP=n on sh, do you have a comment about the reasoning since you have discussed with John? Is it because of below config items? arch/sh/Kconfig: config ARCH_SUPPORTS_CRASH_DUMP def_bool BROKEN_ON_SMP ... config PHYSICAL_START hex "Physical address where the kernel is loaded" if (EXPERT || CRASH_DUMP) default MEMORY_START ... > > Signed-off-by: Dave Vasilevsky <dave@vasilevsky.ca> > Reported-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> > Closes: https://lists.debian.org/debian-powerpc/2024/07/msg00001.html > Fixes: 75bc255a7444 ("crash: clean up kdump related config items") > --- > arch/arm/Kconfig | 3 +++ > arch/arm64/Kconfig | 3 +++ > arch/loongarch/Kconfig | 3 +++ > arch/mips/Kconfig | 3 +++ > arch/powerpc/Kconfig | 4 ++++ > arch/riscv/Kconfig | 3 +++ > arch/s390/Kconfig | 3 +++ > arch/sh/Kconfig | 3 +++ > arch/x86/Kconfig | 3 +++ > kernel/Kconfig.kexec | 2 +- > 10 files changed, 29 insertions(+), 1 deletion(-) > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig > index 54b2bb817a7f..200995052690 100644 > --- a/arch/arm/Kconfig > +++ b/arch/arm/Kconfig > @@ -1597,6 +1597,9 @@ config ATAGS_PROC > config ARCH_SUPPORTS_CRASH_DUMP > def_bool y > > +config ARCH_DEFAULT_CRASH_DUMP > + def_bool y > + > config AUTO_ZRELADDR > bool "Auto calculation of the decompressed kernel image address" if !ARCH_MULTIPLATFORM > default !(ARCH_FOOTBRIDGE || ARCH_RPC || ARCH_SA1100) > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig > index a2f8ff354ca6..43e08cc8204f 100644 > --- a/arch/arm64/Kconfig > +++ b/arch/arm64/Kconfig > @@ -1558,6 +1558,9 @@ config ARCH_DEFAULT_KEXEC_IMAGE_VERIFY_SIG > config ARCH_SUPPORTS_CRASH_DUMP > def_bool y > > +config ARCH_DEFAULT_CRASH_DUMP > + def_bool y > + > config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION > def_bool CRASH_RESERVE > > diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig > index 70f169210b52..ce232ddcd27d 100644 > --- a/arch/loongarch/Kconfig > +++ b/arch/loongarch/Kconfig > @@ -599,6 +599,9 @@ config ARCH_SUPPORTS_KEXEC > config ARCH_SUPPORTS_CRASH_DUMP > def_bool y > > +config ARCH_DEFAULT_CRASH_DUMP > + def_bool y > + > config ARCH_SELECTS_CRASH_DUMP > def_bool y > depends on CRASH_DUMP > diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig > index 60077e576935..b547f4304d0c 100644 > --- a/arch/mips/Kconfig > +++ b/arch/mips/Kconfig > @@ -2881,6 +2881,9 @@ config ARCH_SUPPORTS_KEXEC > config ARCH_SUPPORTS_CRASH_DUMP > def_bool y > > +config ARCH_DEFAULT_CRASH_DUMP > + def_bool y > + > config PHYSICAL_START > hex "Physical address where the kernel is loaded" > default "0xffffffff84000000" > diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig > index d7b09b064a8a..0f3c1f958eac 100644 > --- a/arch/powerpc/Kconfig > +++ b/arch/powerpc/Kconfig > @@ -682,6 +682,10 @@ config RELOCATABLE_TEST > config ARCH_SUPPORTS_CRASH_DUMP > def_bool PPC64 || PPC_BOOK3S_32 || PPC_85xx || (44x && !SMP) > > +config ARCH_DEFAULT_CRASH_DUMP > + bool > + default y if !PPC_BOOK3S_32 > + > config ARCH_SELECTS_CRASH_DUMP > def_bool y > depends on CRASH_DUMP > diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig > index 0f3cd7c3a436..eb247b5ee569 100644 > --- a/arch/riscv/Kconfig > +++ b/arch/riscv/Kconfig > @@ -880,6 +880,9 @@ config ARCH_SUPPORTS_KEXEC_PURGATORY > config ARCH_SUPPORTS_CRASH_DUMP > def_bool y > > +config ARCH_DEFAULT_CRASH_DUMP > + def_bool y > + > config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION > def_bool CRASH_RESERVE > > diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig > index a822f952f64a..05a1fb408471 100644 > --- a/arch/s390/Kconfig > +++ b/arch/s390/Kconfig > @@ -275,6 +275,9 @@ config ARCH_SUPPORTS_CRASH_DUMP > This option also enables s390 zfcpdump. > See also <file:Documentation/arch/s390/zfcpdump.rst> > > +config ARCH_DEFAULT_CRASH_DUMP > + def_bool y > + > menu "Processor type and features" > > config HAVE_MARCH_Z10_FEATURES > diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig > index 1aa3c4a0c5b2..b04cfa23378c 100644 > --- a/arch/sh/Kconfig > +++ b/arch/sh/Kconfig > @@ -549,6 +549,9 @@ config ARCH_SUPPORTS_KEXEC > config ARCH_SUPPORTS_CRASH_DUMP > def_bool BROKEN_ON_SMP > > +config ARCH_DEFAULT_CRASH_DUMP > + def_bool n > + > config ARCH_SUPPORTS_KEXEC_JUMP > def_bool y > > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig > index 007bab9f2a0e..aa4666bb9e9c 100644 > --- a/arch/x86/Kconfig > +++ b/arch/x86/Kconfig > @@ -2087,6 +2087,9 @@ config ARCH_SUPPORTS_KEXEC_JUMP > config ARCH_SUPPORTS_CRASH_DUMP > def_bool X86_64 || (X86_32 && HIGHMEM) > > +config ARCH_DEFAULT_CRASH_DUMP > + def_bool y > + > config ARCH_SUPPORTS_CRASH_HOTPLUG > def_bool y > > diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec > index 6c34e63c88ff..4d111f871951 100644 > --- a/kernel/Kconfig.kexec > +++ b/kernel/Kconfig.kexec > @@ -97,7 +97,7 @@ config KEXEC_JUMP > > config CRASH_DUMP > bool "kernel crash dumps" > - default y > + default ARCH_DEFAULT_CRASH_DUMP > depends on ARCH_SUPPORTS_CRASH_DUMP > depends on KEXEC_CORE > select VMCORE_INFO > -- > 2.34.1 >
On 2024-08-30 02:35, Baoquan He wrote: > The overrall looks good to me except of the CRASH_DUMP=n on sh, do you > have a comment about the reasoning since you have discussed with John? > Is it because of below config items? I don't yet know why John asked to turn this off by default on sh, though I'm sure there's a good reason! John, I'd appreciate if you could chime in. Otherwise, I could split the patch, and we can discuss the default on sh separately from powerpc. -Dave
I received a notification from Patchwork that my patch is now in the state "Handled Elsewhere".[0] Does that mean someone merged it somewhere? Or that I should be using a different mailing list? Or something else? I'd appreciate some guidance. Thanks, Dave [0] http://patchwork.ozlabs.org/project/linuxppc-dev/patch/20240823125156.104775-1-dave@vasilevsky.ca/
On 09/08/24 at 03:57pm, Dave Vasilevsky wrote:
> I received a notification from Patchwork that my patch is now in the state "Handled Elsewhere".[0] Does that mean someone merged it somewhere? Or that I should be using a different mailing list? Or something else?
I guess it's powerpc dev's patchwork which automatically grabs this
patch to do some testing? Becuase ppc list is added in the CC. I don't
think this patch has been picked by people because this is an old v1 and
there's concern about it.
Dave Vasilevsky <dave@vasilevsky.ca> writes: > I received a notification from Patchwork that my patch is now in the > state "Handled Elsewhere".[0] Does that mean someone merged it > somewhere? Or that I should be using a different mailing list? Or > something else? > > I'd appreciate some guidance. It was sent/Cc'ed to linuxppc-dev, so it was picked up by the linuxppc patchwork, which is fine and normal. Because it touches many arches I don't plan to merge it, I would expect the kexec maintainers to take it. So I marked it as "Handled Elsewhere" in the linuxppc patchwork - ie. not handled via the powerpc tree. That doesn't mean anyone else has merged it, it just means I haven't and don't plan to. cheers
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index 54b2bb817a7f..200995052690 100644 --- a/arch/arm/Kconfig +++ b/arch/arm/Kconfig @@ -1597,6 +1597,9 @@ config ATAGS_PROC config ARCH_SUPPORTS_CRASH_DUMP def_bool y +config ARCH_DEFAULT_CRASH_DUMP + def_bool y + config AUTO_ZRELADDR bool "Auto calculation of the decompressed kernel image address" if !ARCH_MULTIPLATFORM default !(ARCH_FOOTBRIDGE || ARCH_RPC || ARCH_SA1100) diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig index a2f8ff354ca6..43e08cc8204f 100644 --- a/arch/arm64/Kconfig +++ b/arch/arm64/Kconfig @@ -1558,6 +1558,9 @@ config ARCH_DEFAULT_KEXEC_IMAGE_VERIFY_SIG config ARCH_SUPPORTS_CRASH_DUMP def_bool y +config ARCH_DEFAULT_CRASH_DUMP + def_bool y + config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION def_bool CRASH_RESERVE diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig index 70f169210b52..ce232ddcd27d 100644 --- a/arch/loongarch/Kconfig +++ b/arch/loongarch/Kconfig @@ -599,6 +599,9 @@ config ARCH_SUPPORTS_KEXEC config ARCH_SUPPORTS_CRASH_DUMP def_bool y +config ARCH_DEFAULT_CRASH_DUMP + def_bool y + config ARCH_SELECTS_CRASH_DUMP def_bool y depends on CRASH_DUMP diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 60077e576935..b547f4304d0c 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -2881,6 +2881,9 @@ config ARCH_SUPPORTS_KEXEC config ARCH_SUPPORTS_CRASH_DUMP def_bool y +config ARCH_DEFAULT_CRASH_DUMP + def_bool y + config PHYSICAL_START hex "Physical address where the kernel is loaded" default "0xffffffff84000000" diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig index d7b09b064a8a..0f3c1f958eac 100644 --- a/arch/powerpc/Kconfig +++ b/arch/powerpc/Kconfig @@ -682,6 +682,10 @@ config RELOCATABLE_TEST config ARCH_SUPPORTS_CRASH_DUMP def_bool PPC64 || PPC_BOOK3S_32 || PPC_85xx || (44x && !SMP) +config ARCH_DEFAULT_CRASH_DUMP + bool + default y if !PPC_BOOK3S_32 + config ARCH_SELECTS_CRASH_DUMP def_bool y depends on CRASH_DUMP diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig index 0f3cd7c3a436..eb247b5ee569 100644 --- a/arch/riscv/Kconfig +++ b/arch/riscv/Kconfig @@ -880,6 +880,9 @@ config ARCH_SUPPORTS_KEXEC_PURGATORY config ARCH_SUPPORTS_CRASH_DUMP def_bool y +config ARCH_DEFAULT_CRASH_DUMP + def_bool y + config ARCH_HAS_GENERIC_CRASHKERNEL_RESERVATION def_bool CRASH_RESERVE diff --git a/arch/s390/Kconfig b/arch/s390/Kconfig index a822f952f64a..05a1fb408471 100644 --- a/arch/s390/Kconfig +++ b/arch/s390/Kconfig @@ -275,6 +275,9 @@ config ARCH_SUPPORTS_CRASH_DUMP This option also enables s390 zfcpdump. See also <file:Documentation/arch/s390/zfcpdump.rst> +config ARCH_DEFAULT_CRASH_DUMP + def_bool y + menu "Processor type and features" config HAVE_MARCH_Z10_FEATURES diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig index 1aa3c4a0c5b2..b04cfa23378c 100644 --- a/arch/sh/Kconfig +++ b/arch/sh/Kconfig @@ -549,6 +549,9 @@ config ARCH_SUPPORTS_KEXEC config ARCH_SUPPORTS_CRASH_DUMP def_bool BROKEN_ON_SMP +config ARCH_DEFAULT_CRASH_DUMP + def_bool n + config ARCH_SUPPORTS_KEXEC_JUMP def_bool y diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 007bab9f2a0e..aa4666bb9e9c 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -2087,6 +2087,9 @@ config ARCH_SUPPORTS_KEXEC_JUMP config ARCH_SUPPORTS_CRASH_DUMP def_bool X86_64 || (X86_32 && HIGHMEM) +config ARCH_DEFAULT_CRASH_DUMP + def_bool y + config ARCH_SUPPORTS_CRASH_HOTPLUG def_bool y diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec index 6c34e63c88ff..4d111f871951 100644 --- a/kernel/Kconfig.kexec +++ b/kernel/Kconfig.kexec @@ -97,7 +97,7 @@ config KEXEC_JUMP config CRASH_DUMP bool "kernel crash dumps" - default y + default ARCH_DEFAULT_CRASH_DUMP depends on ARCH_SUPPORTS_CRASH_DUMP depends on KEXEC_CORE select VMCORE_INFO
Fixes boot failures on 6.9 on PPC_BOOK3S_32 machines using Open Firmware. On these machines, the kernel refuses to boot from non-zero PHYSICAL_START, which occurs when CRASH_DUMP is on. Since most PPC_BOOK3S_32 machines boot via Open Firmware, it should default to off for them. Users booting via some other mechanism can still turn it on explicitly. Also defaults to CRASH_DUMP=n on sh. Signed-off-by: Dave Vasilevsky <dave@vasilevsky.ca> Reported-by: Reimar Döffinger <Reimar.Doeffinger@gmx.de> Closes: https://lists.debian.org/debian-powerpc/2024/07/msg00001.html Fixes: 75bc255a7444 ("crash: clean up kdump related config items") --- arch/arm/Kconfig | 3 +++ arch/arm64/Kconfig | 3 +++ arch/loongarch/Kconfig | 3 +++ arch/mips/Kconfig | 3 +++ arch/powerpc/Kconfig | 4 ++++ arch/riscv/Kconfig | 3 +++ arch/s390/Kconfig | 3 +++ arch/sh/Kconfig | 3 +++ arch/x86/Kconfig | 3 +++ kernel/Kconfig.kexec | 2 +- 10 files changed, 29 insertions(+), 1 deletion(-)