lkml.org 
[lkml]   [2009]   [Oct]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] [RFC][Patch x86-tip] add notifier before kdump
On Tue, Oct 27, 2009 at 05:39:40PM +0900, Jin Dongming wrote:
> When the kernel is going on panic, there are three groups of people
> who want to do something for themselves at that time:
> 1. Only do the work for notifying
> 2. Only do the work for kdump
> 3. Want to do both of the above, notifying and kdump
>
> The first and second have been done well on current kernel, but we
> can not satisfy 3rd when kdump is used, because notify_die() is located
> after crash_kexec(). So I think we can do some work to make it working
> well. And I am also the person who stand in the third group.
>
> In our PC-cluster, there are two nodes working together, one is running
> and the other one is on standby mode. When the running one is going
> on panic, we hope the works listed as following would be done:
> 1. Before the running kernel is going on panic, the node on standby
> mode should be notified firstly.
> 2. After the notified work is done, the panic kernel startup on the
> second kernel to get kdump.
> But the current kernel could not do them all.
>
> For resolving this problem,I made this patch.
> In my patch, because I don't want to give impact to both of all, notifying
> and kdump, I do following work:
> 1. I add crash_notifier instead of the existing notify_die().
> So the original functionality of notify_die() will not be changed. I
> made all of the work done just before kdump will be got.
> 2. I add a switch to turn on/off crash_notifier.
> This switch could be turned on/off according to your request. For
> example, when kdump is only required to be done, the crash_notifier is
> not need any more, so the switch could be turned off.
> Also there will be not impact to the second kernel. Because it is valid
> only when the flag for crash_notifier is set via a parameter of kernel.
>
> This patch is not tested on SH and Power PC.
>

I guess this might be 3rd or 4th attempt to get this kind of
infrastructure in kernel.

In the past exporting this kind of hook to modules has been rejected
becuase of concerns that modules might be doing too much in side a
crashed kernel and that can hang up the system completely and we can't
even capture the dump.

In the past two ways have been proposed to handle this situation.

- Handle it in second kernel. Especially in initrd. Put right
script/binary/tools and configuration in kdump initrd at the time of
configuration and once second kernel boots, initrd will first send the
kdump message out to other node(s). This can be helpful for fencing
scenario also.

- Other thing, I think Eric Biederman suggested was that we need to see
the code that will be executed after crash so that it can be audited and
keep it in kernel instead of blindly exporting a hook to module and let
module do whatever it want to do.

So my question is, how about introducing some infrastructure in kdump
initrd to send a notification out?

Thanks
Vivek

> Signed-off-by: Akiyama, Nobuyuki <akiyama.nobuyuk@jp.fujitsu.com>
> Signed-off-by: Jin Dongming <jin.dongming@np.css.fujitsu.com>
> ---
> include/linux/kexec.h | 2 ++
> kernel/kexec.c | 24 ++++++++++++++++++++++++
> 2 files changed, 26 insertions(+), 0 deletions(-)
>
> diff --git a/include/linux/kexec.h b/include/linux/kexec.h
> index adc34f2..c50158c 100644
> --- a/include/linux/kexec.h
> +++ b/include/linux/kexec.h
> @@ -9,6 +9,7 @@
> #include <linux/ioport.h>
> #include <linux/elfcore.h>
> #include <linux/elf.h>
> +#include <linux/notifier.h>
> #include <asm/kexec.h>
>
> /* Verify architecture specific macros are defined */
> @@ -158,6 +159,7 @@ unsigned long paddr_vmcoreinfo_note(void);
>
> extern struct kimage *kexec_image;
> extern struct kimage *kexec_crash_image;
> +extern struct raw_notifier_head crash_notifier_list;
>
> #ifndef kexec_flush_icache_page
> #define kexec_flush_icache_page(page)
> diff --git a/kernel/kexec.c b/kernel/kexec.c
> index f336e21..147f22d 100644
> --- a/kernel/kexec.c
> +++ b/kernel/kexec.c
> @@ -31,6 +31,8 @@
> #include <linux/cpu.h>
> #include <linux/console.h>
> #include <linux/vmalloc.h>
> +#include <linux/module.h>
> +#include <linux/notifier.h>
>
> #include <asm/page.h>
> #include <asm/uaccess.h>
> @@ -38,6 +40,10 @@
> #include <asm/system.h>
> #include <asm/sections.h>
>
> +/* crash notifier list */
> +RAW_NOTIFIER_HEAD(crash_notifier_list);
> +EXPORT_SYMBOL(crash_notifier_list);
> +
> /* Per cpu memory for storing cpu states in case of system crash. */
> note_buf_t* crash_notes;
>
> @@ -1060,6 +1066,14 @@ asmlinkage long compat_sys_kexec_load(unsigned long entry,
> }
> #endif
>
> +static int crash_notifier_valid __read_mostly;
> +
> +static void notify_crash(void)
> +{
> + if (crash_notifier_valid)
> + raw_notifier_call_chain(&crash_notifier_list, 0, 0);
> +}
> +
> void crash_kexec(struct pt_regs *regs)
> {
> /* Take the kexec_mutex here to prevent sys_kexec_load
> @@ -1076,6 +1090,7 @@ void crash_kexec(struct pt_regs *regs)
> crash_setup_regs(&fixed_regs, regs);
> crash_save_vmcoreinfo();
> machine_crash_shutdown(&fixed_regs);
> + notify_crash();
> machine_kexec(kexec_crash_image);
> }
> mutex_unlock(&kexec_mutex);
> @@ -1502,3 +1517,12 @@ int kernel_kexec(void)
> mutex_unlock(&kexec_mutex);
> return error;
> }
> +
> +static int __init kexec_crash_notifier_valid(char *str)
> +{
> + crash_notifier_valid = 1;
> +
> + return 1;
> +}
> +
> +__setup("crash_notifier", kexec_crash_notifier_valid);
> --
> 1.6.2.2
>


\
 
 \ /
  Last update: 2009-10-27 16:09    [W:0.090 / U:0.300 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site