linux-kernel - Re: RFC: Put printk buffer in video ram

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <4B0ADA84.5050300@nortel.com>
Date:	Mon, 23 Nov 2009 12:55:00 -0600
From:	"Chris Friesen" <cfriesen@...tel.com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Maxim Levitsky <maximlevitsky@...il.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Arjan van de Ven <arjan@...radead.org>,
	Dave Jones <davej@...hat.com>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: RFC: Put printk buffer in video ram

On 11/23/2009 12:32 PM, Ingo Molnar wrote:
> 
> * Maxim Levitsky <maximlevitsky@...il.com> wrote:
> 
>> On Sun, 2009-11-22 at 14:15 +0200, Maxim Levitsky wrote: 
>>> On Sun, 2009-11-22 at 09:25 +0100, Ingo Molnar wrote: 
>>>> * Frederic Weisbecker <fweisbec@...il.com> wrote:
>>>>
>>>>> On Sun, Nov 22, 2009 at 04:05:06AM +0200, Maxim Levitsky wrote:
>>>>>> After doing some successful debugging by placing printk buffer in video
>>>>>> ram, here I publish cleaned version of it.
>>>>>>
>>>>>> I discovered that on my system video ram isn't cleared on reboot, and I
>>>>>> took advantage of that by placing printk buffer directly there.
>>>>>> This allows to capture oopses/panicks almost from everywhere.
>>>>>> It is also very simple to setup.
>>
>> Few more thoughts:
>>
>> First of all, if I implement this as a console driver, I won't be able
>> to capture all kernel log, but only from the point I register the
>> console.
> 
> Adding an early console driver would solve this, right?

We've had a mechanism sort of like this for quite a while.  Hasn't been
pushed to mainline because it used board-specific hardware and we're
usually multiple kernel versions behind mainline.

Anyways, a couple things that we've found to be useful are:
1) The ability to allocate a chunk of this persistent memory area for a
special purpose.  This allows things like memory-mapped circular buffers
for per-cpu binary data.
2) An API to log just to this persistent area and bypass the normal
console completely.  This can be useful when debugging issues where the
normal logging paths result in a hang.

Chris
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/