[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20150805145332.GB18217@pathway.suse.cz>
Date: Wed, 5 Aug 2015 16:53:32 +0200
From: Petr Mladek <pmladek@...e.com>
To: check.kernel@...il.com
Cc: 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>,
Alex Elder <elder@...aro.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>,
linux-kernel@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
yangdongdong <yangdongdong@...omi.com>
Subject: Re: [PATCH] ramoops: provide panic data even in suspend
On Wed 2015-08-05 21:56:07, check.kernel@...il.com wrote:
> From: yangdongdong <yangdongdong@...omi.com>
>
> Good comments. It is valuable for code readable. Here is not necessary wrap atomic_notifier_chain_register into ramoops_prepare. The updated patch as below:
>
> >From 5ec3976e2b55dfaf8bd1bc88c5a9c05762148fef Mon Sep 17 00:00:00 2001
> From: yangdongdong <yangdongdong@...omi.com>
> Date: Wed, 5 Aug 2015 18:51:17 +0800
> Subject: [PATCH] ramoops: provide panic data even in suspend
>
> This 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>
> ---
> fs/pstore/ram.c | 16 ++++++++++++++++
> include/linux/pstore_ram.h | 1 +
> kernel/printk/printk.c | 6 ++++++
> 3 files changed, 23 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();
IMHO, you need to make sure that this is called only when the console
is suspended.
Well, the panic might come at any time, for example when the
console is being suspended. In this case, you might not be able
to take the console semaphore and you might break panic().
A solution might be to call zap_locks(). But Peter Zijlstra is
against using zap_locks() because it might cause losing
messages. He suggests to print to safe consoles directly,
something like the x86 early_serial_console.
Best Regards,
Petr
> +
> + 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..ece645c 100644
> --- a/kernel/printk/printk.c
> +++ b/kernel/printk/printk.c
> @@ -2107,6 +2107,12 @@ void resume_console(void)
> console_unlock();
> }
>
> +void emergency_unlock_console(void)
> +{
> + resume_console();
> +}
> +EXPORT_SYMBOL(emergency_unlock_console);
> +
> /**
> * console_cpu_notify - print deferred console messages after CPU hotplug
> * @self: notifier struct
> --
> 2.5.0
>
> 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