From: Nir Lichtman <[email protected]>
Date: Sat, 3 Feb 2024 10:19:30 +0200
Subject: [PATCH] kernel: add boot param to disable stack dump on panic
---
Documentation/admin-guide/kernel-parameters.txt | 5 +++++
kernel/panic.c | 12 +++++++++++-
2 files changed, 16 insertions(+), 1 deletion(-)
diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 31b3a2568..433e3e5d1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1127,6 +1127,11 @@
MTRR settings. This parameter disables that behavior,
possibly causing your machine to run very slowly.
+ disable_stack_dump_on_panic
+ This parameter disables call stack dumping when there
+ is a panic, which can help obscure less earlier messages
+ that lead to the panic.
+
disable_timer_pin_1 [X86]
Disable PIN 1 of APIC timer
Can be useful to work around chipset bugs.
diff --git a/kernel/panic.c b/kernel/panic.c
index 2807639aa..a1e1d064e 100644
--- a/kernel/panic.c
+++ b/kernel/panic.c
@@ -266,6 +266,16 @@ static void panic_other_cpus_shutdown(bool crash_kexec)
crash_smp_send_stop();
}
+static int disable_stack_dump_on_panic __initdata;
+
+static int __init disable_stack_dump_on_panic_setup(char *str)
+{
+ disable_stack_dump_on_panic = 1;
+ return 0;
+}
+
+early_param("disable_stack_dump_on_panic", disable_stack_dump_on_panic_setup);
+
/**
* panic - halt the system
* @fmt: The text string to print
@@ -340,7 +350,7 @@ void panic(const char *fmt, ...)
/*
* Avoid nested stack-dumping if a panic occurs during oops processing
*/
- if (!test_taint(TAINT_DIE) && oops_in_progress <= 1)
+ if (!test_taint(TAINT_DIE) && oops_in_progress <= 1 && !disable_stack_dump_on_panic)
dump_stack();
#endif
--
2.39.2
On Tue, Feb 06, 2024 at 09:39:02PM +0000, Nir Lichtman wrote:
> From: Nir Lichtman <[email protected]>
> Date: Sat, 3 Feb 2024 10:19:30 +0200
> Subject: [PATCH] kernel: add boot param to disable stack dump on panic
>
Can you describe why this patch is needed (or beneficial)?
Confused...
--
An old man doll... just what I always wanted! - Clara
In a lot of cases when there is a kernel panic it obscures on the display the previous problem that caused it and the main
reason is that the call stack prints a lot of lines on the display - and there is no way to scroll back up.
What led me to make this patch is that I was working on running the kernel on my old computer and when I passed root=/dev/sda
to the kernel there was a panic and it could not start init, but since the call stack took almost all the space on the screen,
I couldn't see the available partitions the kernel does detects.
After this patch, I could just pass in the new boot parameter I added here and then it would not print the call stack,
and I saw the line in which the kernel prints the available partitions.
On Wed, Feb 07, 2024 at 09:10:22AM +0700, Bagas Sanjaya wrote:
> On Tue, Feb 06, 2024 at 09:39:02PM +0000, Nir Lichtman wrote:
> > From: Nir Lichtman <[email protected]>
> > Date: Sat, 3 Feb 2024 10:19:30 +0200
> > Subject: [PATCH] kernel: add boot param to disable stack dump on panic
> >
>
> Can you describe why this patch is needed (or beneficial)?
>
> Confused...
>
> --
> An old man doll... just what I always wanted! - Clara
On 2/8/24 15:14, Nir Lichtman wrote:
> In a lot of cases when there is a kernel panic it obscures on the display the previous problem that caused it and the main
> reason is that the call stack prints a lot of lines on the display - and there is no way to scroll back up.
> What led me to make this patch is that I was working on running the kernel on my old computer and when I passed root=/dev/sda
> to the kernel there was a panic and it could not start init, but since the call stack took almost all the space on the screen,
> I couldn't see the available partitions the kernel does detects.
>
> After this patch, I could just pass in the new boot parameter I added here and then it would not print the call stack,
> and I saw the line in which the kernel prints the available partitions.
>
Please don't top-post; reply inline with appropriate context instead.
Thanks for the explanation. Now please send v2 with appropriate maintainers
and lists Cc'ed (use scripts/get_maintainer.pl to find ones). Also read
Documentation/process/submitting-patches.rst before sending.
Ciao!
--
An old man doll... just what I always wanted! - Clara
On Fri, Feb 09, 2024 at 04:22:12PM +0700, Bagas Sanjaya wrote:
> On 2/8/24 15:14, Nir Lichtman wrote:
> > In a lot of cases when there is a kernel panic it obscures on the display the previous problem that caused it and the main
> > reason is that the call stack prints a lot of lines on the display - and there is no way to scroll back up.
> > What led me to make this patch is that I was working on running the kernel on my old computer and when I passed root=/dev/sda
> > to the kernel there was a panic and it could not start init, but since the call stack took almost all the space on the screen,
> > I couldn't see the available partitions the kernel does detects.
> >
> > After this patch, I could just pass in the new boot parameter I added here and then it would not print the call stack,
> > and I saw the line in which the kernel prints the available partitions.
> >
>
> Please don't top-post; reply inline with appropriate context instead.
>
> Thanks for the explanation. Now please send v2 with appropriate maintainers
> and lists Cc'ed (use scripts/get_maintainer.pl to find ones). Also read
> Documentation/process/submitting-patches.rst before sending.
>
> Ciao!
>
> --
> An old man doll... just what I always wanted! - Clara
>
Yah I read the docs about submitting patches and ran the get_maintainer script but it didn't find anything for the
changes I made (except documentation maintainers), I guess maybe the panic.c file has no main mantainer?
Thanks,
On 2/9/24 01:50, Nir Lichtman wrote:
> On Fri, Feb 09, 2024 at 04:22:12PM +0700, Bagas Sanjaya wrote:
>> On 2/8/24 15:14, Nir Lichtman wrote:
>>> In a lot of cases when there is a kernel panic it obscures on the display the previous problem that caused it and the main
>>> reason is that the call stack prints a lot of lines on the display - and there is no way to scroll back up.
>>> What led me to make this patch is that I was working on running the kernel on my old computer and when I passed root=/dev/sda
>>> to the kernel there was a panic and it could not start init, but since the call stack took almost all the space on the screen,
>>> I couldn't see the available partitions the kernel does detects.
>>>
>>> After this patch, I could just pass in the new boot parameter I added here and then it would not print the call stack,
>>> and I saw the line in which the kernel prints the available partitions.
>>>
>>
>> Please don't top-post; reply inline with appropriate context instead.
>>
>> Thanks for the explanation. Now please send v2 with appropriate maintainers
>> and lists Cc'ed (use scripts/get_maintainer.pl to find ones). Also read
>> Documentation/process/submitting-patches.rst before sending.
>>
>> Ciao!
>>
>> --
>> An old man doll... just what I always wanted! - Clara
>>
>
> Yah I read the docs about submitting patches and ran the get_maintainer script but it didn't find anything for the
> changes I made (except documentation maintainers), I guess maybe the panic.c file has no main mantainer?
True, it doesn't have a primary maintainer. You can use
$ git log kernel/panic.c
to see who has been merging patches for it.
Examples:
Andrew Morton
Petr Mladek (printk or log buffer related)
Ingo Molnar (preemption related)
etc.
If in doubt, Andrew Morton is usually a good guess.
--
#Randy