Re: [RFC][PATCH v4 -next 1/4] Move kmsg_dump(KMSG_DUMP_PANIC) belowsmp_send_stop()

From: Chen Gong
Date: Wed Jan 11 2012 - 02:28:19 EST


ä 2012/1/11 4:29, Seiji Aguchi åé:

I agree with you. How about adding macros or something like WARN_ON(XX_ARCH) or
Kconfig to limit its scope?

Thank you for giving me your idea.
Your suggestions above will work for me because I'm a x86 user.
If Tony agrees to it, I can update my patch.

But, I'm hesitating to add WARN_ON() or change Kconfig only for specific arch
because pstore aims for generic interface and this is related to its design.
Also, ramoops is going to use pstore now. It doesn't depend on x86.
I'm worried that ramoops users will complain about this change.

So, I think a reasonable solution at this time is just adding some explanations
about smp_send_stop() to documentation as follows.

Users can use pstore with their own responsibility and ask developers
if smp_send_stop() is reliable enough in panic situation on architecture they want to run.

What do you think?

---
Documentation/ABI/testing/pstore | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)

diff --git a/Documentation/ABI/testing/pstore b/Documentation/ABI/testing/pstore
index ff1df4e..5583729 100644
--- a/Documentation/ABI/testing/pstore
+++ b/Documentation/ABI/testing/pstore
@@ -11,6 +11,14 @@ Description: Generic interface to platform dependent persistent storage.
of the console log is captured, but other interesting
data can also be saved.

+ In case of panic, pstore is invoked after smp_send_stop()
+ ,a function call stopping other cpus, so that we can get
+ logs simpler and cleaner with just one running cpu.
+
+ As for x86, smp_send_stop() is reliable enough to work in
+ panic situation. But we are not guaranteed that it works
+ reliably on other architectures.
+
# mount -t pstore -o kmsg_bytes=8000 - /dev/pstore

$ ls -l /dev/pstore

The explanation is great. but In my opinion, I still insist that
a WARN_ON() is necessary. What do you think, Tony and Don?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/