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: <4AE948D6.2080809@np.css.fujitsu.com>
Date:	Thu, 29 Oct 2009 16:48:38 +0900
From:	Jin Dongming <jin.dongming@...css.fujitsu.com>
To:	"Eric W. Biederman" <ebiederm@...ssion.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

Hi Eric

Thanks for your comment.
I will consider the method you suggested. Thank you very much.

Best regards,
Jin Dongming

Eric W. Biederman wrote:
> 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/
> 
> 


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