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-next>] [day] [month] [year] [list]
Message-Id: <1439351152-10836-1-git-send-email-check.kernel@gmail.com>
Date:	Wed, 12 Aug 2015 11:45:52 +0800
From:	<check.kernel@...il.com>
To:	Petr Mladek <pmladek@...e.cz>, Alex Elder <elder@...aro.org>,
	Anton Vorontsov <anton@...msg.org>,
	Colin Cross <ccross@...roid.com>,
	Kees Cook <keescook@...omium.org>,
	Tony Luck <tony.luck@...el.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Luis R. Rodriguez" <mcgrof@...e.com>,
	Peter Hurley <peter@...leysoftware.com>,
	Joe Perches <joe@...ches.com>, Tejun Heo <tj@...nel.org>,
	Ethan du <duhui@...omi.com>, Linghua Gu <gulinghua@...omi.com>
Cc:	linux-kernel@...r.kernel.org,
	yangdongdong <yangdongdong@...omi.com>
Subject: [PATCH v3] fs/pstore: provide panic data even in suspend

From: yangdongdong <yangdongdong@...omi.com>

If system restart after panic, this patch also enables
panic and oops messages which in suspend context to be
logged into ramoops console buffer where it can be read
back at some later point.

Signed-off-by: yangdongdong <yangdongdong@...omi.com>
Signed-off-by: gulinghua <gulinghua@...omi.com>
Signed-off-by: duhui <duhui@...omi.com>
---
 fs/pstore/ram.c            | 16 ++++++++++++++++
 include/linux/pstore_ram.h |  1 +
 kernel/printk/printk.c     |  7 +++++++
 3 files changed, 24 insertions(+)

diff --git a/fs/pstore/ram.c b/fs/pstore/ram.c
index 6c26c4d..3d981a1 100644
--- a/fs/pstore/ram.c
+++ b/fs/pstore/ram.c
@@ -642,8 +642,23 @@ static void ramoops_register_dummy(void)
 	}
 }
 
+static int ramoops_console_notify(struct notifier_block *this,
+		unsigned long event, void *ptr)
+{
+	pr_emerg("ramoops unlock console ...\n");
+	emergency_unlock_console();
+
+	return 0;
+}
+
+static struct notifier_block ramoop_nb = {
+	.notifier_call = ramoops_console_notify,
+	.priority = INT_MAX,
+};
+
 static int __init ramoops_init(void)
 {
+	atomic_notifier_chain_register(&panic_notifier_list, &ramoop_nb);
 	ramoops_register_dummy();
 	return platform_driver_register(&ramoops_driver);
 }
@@ -654,6 +669,7 @@ static void __exit ramoops_exit(void)
 	platform_driver_unregister(&ramoops_driver);
 	platform_device_unregister(dummy);
 	kfree(dummy_data);
+	atomic_notifier_chain_unregister(&panic_notifier_list, &ramoop_nb);
 }
 module_exit(ramoops_exit);
 
diff --git a/include/linux/pstore_ram.h b/include/linux/pstore_ram.h
index 9c9d6c1..826a35b 100644
--- a/include/linux/pstore_ram.h
+++ b/include/linux/pstore_ram.h
@@ -52,6 +52,7 @@ struct persistent_ram_zone {
 	size_t old_log_size;
 };
 
+extern void emergency_unlock_console(void);
 struct persistent_ram_zone *persistent_ram_new(phys_addr_t start, size_t size,
 			u32 sig, struct persistent_ram_ecc_info *ecc_info,
 			unsigned int memtype);
diff --git a/kernel/printk/printk.c b/kernel/printk/printk.c
index cf8c242..ca02094 100644
--- a/kernel/printk/printk.c
+++ b/kernel/printk/printk.c
@@ -2107,6 +2107,13 @@ void resume_console(void)
 	console_unlock();
 }
 
+void emergency_unlock_console(void)
+{
+	if (panic_timeout != 0 && console_suspended)
+		resume_console();
+}
+EXPORT_SYMBOL(emergency_unlock_console);
+
 /**
  * console_cpu_notify - print deferred console messages after CPU hotplug
  * @self: notifier struct
-- 
2.5.0

Following is the difference between v2 and v3:
 void emergency_unlock_console(void)
 {
-       if (panic_timeout != 0)
+       if ((panic_timeout != 0) && console_suspended)
                resume_console();
 }
 EXPORT_SYMBOL(emergency_unlock_console);

Once system kernel panic with nonzero panic_timeout value, we hope the debugging
information could be dumped and system could be recovered by reboot.

Since it is emergency case before system reboot, no whether it is triggered by
watchdog or emergency_restart, the debugging data is important for us to
be read back at some later point and system would have no possible enter suspend and resume.
And usually dump panic data process would be hoped to handle in atomic process.
That is why no console_suspended check for emergency_unlock_console at the PATCH-V2.
Here is updating it to [PATCH v3], also add console_suspended check for
emergency_unlock_console, which specific invoked conosole_suspended previously.

Due to no panic information, if we use current ram console approach once panic occurs
on system enter suspend, we would not know who is the trouble maker. We have such
experience at receiving big noise in MO call under system suspend. That is the intention to add the patch.


Thanks,
Andy

--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ