[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ed358bfb-9603-4c73-bc20-0980a9678f73@infradead.org>
Date: Fri, 9 Feb 2024 15:13:10 -0800
From: Randy Dunlap <rdunlap@...radead.org>
To: Nir Lichtman <nir@...htman.org>, Bagas Sanjaya <bagasdotme@...il.com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] kernel: add boot param to disable stack dump on panic
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
Powered by blists - more mailing lists