lkml.org 
[lkml]   [2012]   [Jul]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRE: [RFC][PATCH 2/2] write callback: Check if existing entry is erasable
Date
Don,

Thank you for giving me your comments.
Let me explain what I'm thinking now.

> I would rather see no records overwritten and just make sure there is enough space for a dozen or so records to buffer multiple
> panics before userspace can run.
>
> Implementing policy like this in the kernel seems like it would be a constant battle between everyone's view point of what is
> important and not important.
>
> I would rather take the viewpoint, if it is important to log it in a space limited NVRAM, then it is important enough not to overwrite
> until userspace explicitly asks it to be deleted. Otherwise why log it, if it is not important?
>

If the simple policy above is workable, it is easy.
But we have to discuss whether it is useful in each specific use case.
When I posted a patch introducing kernel parameter ,efi_pstore_overwrite,
I thought same thing above. But I changed my mind while considering Tony's comment....

When an user can read kmsg via /dev/pstore and erase old entries, we don't need to care.
(Hopefully, some user space apps will be developed near future.)

Problem here is at very final stage and early stage which an user can't see /dev/pstore.

1) At very final stage (system is panicking/rebooting.)

1-1) Kernel panics while system is rebooting(or oopsing)

When kernel panics while system is rebooting, panic message should be logged rather than skipping it.

Even though reboot message is overwritten by panic one, we will probably save both final part of
reboot message and panic message as follows.

Example of kmsg in NVRAM
<snip>
Panic#1 <- header supplied by pstore
<6>kvm: exiting hardware virtualization
<5>sd 0:0:0:0: [sda] Synchronizing SCSI cache
<0>Restarting system. <- reboot message
<0>BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
<0> Kernel panic - not syncing: softlockup: hung tasks <- panic message
<0>Pid: 0, comm: swapper/0 Not tainted 3.3.8 #4 Call Trace:
<0><IRQ> [<ffffffff8136bdd5>] panic+0xb8/0x1c4
<0>[<ffffffff81071f37>] watchdog_timer_fn+0x139/0x15d
<0>[<ffffffff81071dfe>] ? __touch_watchdog+0x1f/0x1f
<snip>

1-2) Double panic
In this case, 1s panic message should not be overwritten to detect root cause of system failure.

1-3) ) Kernel reboots while system is panicking
Never happens because kmsg_dump in panic case is serialized via smp_send_stop()

2) At very early stage (system is booting up.)
2-1)Previous event is panic, and then panic happens again at boot time.
Previous panic should not be overwritten.

2-2)Previous event is reboot, and then panic happens at boot time
This depends on situation.
Some customer would like to have previous reboot message.
Others may want to get latter panic message.

So, in my current patch, I just decided a policy which error message is prioritized higher than normal message.

In the most case, an user can read/erase entries in NVRAM and get all messages.
I think it is understandable setting a policy in preparation for rare situation.

Seiji


\
 
 \ /
  Last update: 2012-07-05 22:41    [W:0.065 / U:0.668 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site