From: Nir Lichtman <nir@lichtman.org>
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 <nir@lichtman.org>
> 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 <nir@lichtman.org>
> > 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