linux-kernel - Re: [PATCH] kernel/panic: Add "late_kdump" option for kdump in unstable condition

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: <20140415140853.GA17018@redhat.com>
Date:	Tue, 15 Apr 2014 10:08:53 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc:	linux-kernel@...r.kernel.org,
	Satoru MORIYA <satoru.moriya.br@...achi.com>,
	Yoshihiro YUNOMAE <yoshihiro.yunomae.ez@...achi.com>,
	Takenori Nagano <t-nagano@...jp.nec.com>,
	Eric Biederman <ebiederm@...ssion.com>,
	Motohiro Kosaki <Motohiro.Kosaki@...fujitsu.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] kernel/panic: Add "late_kdump" option for kdump in
 unstable condition

On Tue, Apr 15, 2014 at 10:37:40AM +0900, Masami Hiramatsu wrote:

[..]
> > Masami,
> > 
> > So what's the alternative to kdump which is more reliable? IOW, what
> > action you are planning to take through kmsg_dump() or through
> > panic_notifiers?
> > 
> > I have seen that many a times developers have tried to make the case 
> > to save kernel buffers to NVRAM. Does it work well? Has it been proven
> > to be more reliable than kdump?
> 
> Yeah, one possible option is the NVRAM, but even with the serial,
> there are other reasons to kick the notifiers, e.g.
>  - dump to ipmi which has a very small amount of non-volatile memory
>  - ftrace_dump() to dump "flight recorder" log to serial

So why do we need to run them in crashed kernel? Only argument I seem
to receive that there is no guarantee that kdump kernel will successfully
boot hence we want to run these notifiers.

But what's the guarantee that these will run successfully without creating
futher issues? Is there data to prove it.

>  - pvpanic notifies panic to the host.

I think this pvpanic() notification can go in kdump kernel too? Anyway,
if one has configured kdump, then host does not have to do anything to
save dump. Host might want to know for informational purposes that panic
happend and system rebooted. So there should not be any need to send
this notification immediately after crash?

> 
> Anyway, I think the most important reason for linux developers is
> that we have a chance to improve such horrible notifiers to safer,

I think big debate here is that we should be able to do most of it
in second kernel. 

If you provide a knob to run these in first kernel, this functionality
will never migrate to second kernel. And trying to make them safe in
crashed kernel is a losing battle, I think.

So providing this knob does not help with making these notifiers better.
These notifiers can become better only if migrate the functionality
to second kernel (preferrably in user space). There we can extract all
the data from /proc/vmcore and send it whereever you want.

But for that you will have to trust kdump and keep on improving it
constantly so that it works reasonably well.

> or at least to clarify what notifier or behavior makes kdump unstable. :-)
> 

I think that's well known. We don't have to provide a knob to prove that
running notifiers will make kdump less reliable.

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