linux-kernel - Re: [PATCH] [RFC][Patch x86-tip] add notifier before kdump

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-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <m1fx927okr.fsf@fess.ebiederm.org>
Date:	Wed, 28 Oct 2009 22:32:04 -0700
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Jin Dongming <jin.dongming@...css.fujitsu.com>
Cc:	Lon Hohberger <lhh@...hat.com>, Vivek Goyal <vgoyal@...hat.com>,
	LKLM <linux-kernel@...r.kernel.org>,
	Kenji Kaneshige <kaneshige.kenji@...fujitsu.com>,
	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>,
	Neil Horman <nhorman@...hat.com>
Subject: Re: [PATCH] [RFC][Patch x86-tip] add notifier before kdump

Jin Dongming <jin.dongming@...css.fujitsu.com> writes:

> Vivek, Lon Hohberger
>
> Thanks for your comments.
>
> I also agree with your opinion, too. But I still have problems listed
> as following.
>     1. Nobody knows when the second kernel does not work well
>     2. Too much time cost to startup the second kernel
>
> So I hope that following work could be done. 
>     1. Add some code before kdump to monitor the actions of second kernel
>        Something we worried about is that nobody knows when the kdump will not
>        work well. If the second kernel does not work well, nobody knows when
>        the best time is to restart. So we need to add some code such as setting
>        watchdog. If we want to monitor second kernel, some work need to be done
>        before it starts to work.

Any extra work done in the crashing kernel decreases the likely hood
of the second kernel working.  If you want a watchdog I recommend you always
run it and have the interval set large enough for the second kernel to boot
before it starts petting it.  That way no code needs to run after a kernel crash.

>     2. Shorten the startup time of second kernel
>        I think that the purpose of second kernel is used for backup information
>        stored in memory to storage only. But the time cost is different
>        according to the system architecture. And also I think that there are
>        too many of device is not useful to get the memory information to
>        storage. I think the startup time of second kernel should be shortened.
>        I don't know much about second kernel, these are only my thought.

The second kernel can be anything you like.  Including a standalone executable
if needed for very precise requirements.  Any improvements in boot time for a
normal linux image should apply to the dump kernel.

Currently with a tight initrd and just dumping dmesg to disk I get away with
a 20M crashkernel reservation, and it typically runs and does it's work before
my watchdog fires.

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