[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <A5ED84D3BB3A384992CBB9C77DEDA4D40FB27FAA@USINDEM103.corp.hds.com>
Date: Thu, 19 Jul 2012 21:11:44 +0000
From: Seiji Aguchi <seiji.aguchi@....com>
To: "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"Luck, Tony (tony.luck@...el.com)" <tony.luck@...el.com>,
"mikew@...gle.com" <mikew@...gle.com>,
"dzickus@...hat.com" <dzickus@...hat.com>,
"Matthew Garrett (mjg@...hat.com)" <mjg@...hat.com>
CC: "dle-develop@...ts.sourceforge.net"
<dle-develop@...ts.sourceforge.net>,
Satoru Moriya <satoru.moriya@....com>
Subject: [RFC][PATCH v2 0/3] efi_pstore: avoid losing critical message
This patchset avoids losing a critical message like panic in NVRAM.
[Problem]
Currently, efi_pstore driver simply overwrites existing panic messages in NVRAM.
So, in the following scenario, we will lose 1st panic messages.
1. kernel panics.
2. efi_pstore is kicked and write panic messages to NVRAM.
3. system reboots.
4. kernel panics again before a user checks the 1st panic messages in NVRAM.
[Solution]
To avoid losing a critical message, this patchset is based on a following concept.
- A basic policy is _not_ to overwrite existing entries.
- However, if kernel panics while a system is rebooting, a critical message
can't be saved by the policy above.
(In this case, panic message is critical.)
- So, two approaches are taken by this patchset.
- First one is holding multiple logs.
- Second one is introducing some logic overwriting entries
for holding just one log.
[Patch Descriptions]
Patch 1/3 and 2/3 take fist approach, _not_ overwriting entries.
Patch 3/3 takes second approach, adding some logic overwriting entries.
1/3: Avoid overwriting existing entry
This patch just avoid overwriting entries to save the 1st critical message
without being influenced by subsequent events.
2/3: Hold multiple logs
With this patch, efi_pstore can hold multiple logs.
We can simply avoid losing a critical message in case mutiple events happen.
3/3: Check if existing entry is erasable
This patch adds some logic checking if an existing entry is erasable for
holding just one log.
If users decide that NVRAM size is not big enough to hold multiple logs,
efi_pstore have to handle just one log and avoid a critical messages by
overwriting existing entry.
NVRAM size may vary among different boxes, and the appropriate log size depends
on each user's system. efi_pstore should be flexible in preparation for various
user's choice.
Change v1 -> v2
1/3
- Freshly created to avoid overwriting entries.
2/3
- Freshly created to handle multiple logs.
- Add an additional change passing ctime to arguments of erase_callback.
3/3
- This is based on previous 2/2 patch
- Add comments to kernel/printk.h in preparation for future change
without considering this patch.
- Remove infinite loop to avoid potential hang up.
- Add CFLAGS, -Wswitch-enum and remove default case from switch sentence
in preparation for future change without considering this patch.
- Change a return value to -EEXIST when an erasable entry is not found.
- Remove KMSG_DUMP_UNDEF from kmsg_dump_reason because no one uses it.
Documentation/kernel-parameters.txt | 6 +
drivers/acpi/apei/erst.c | 4 +-
drivers/firmware/Makefile | 2 +
drivers/firmware/efivars.c | 212 +++++++++++++++++++++++++++++++----
fs/pstore/inode.c | 2 +-
fs/pstore/platform.c | 4 +-
fs/pstore/ram.c | 2 +-
include/linux/kmsg_dump.h | 8 +-
include/linux/pstore.h | 7 +-
9 files changed, 214 insertions(+), 33 deletions(-)
--
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/
Powered by blists - more mailing lists