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]
Date:	Thu, 03 Jun 2010 11:30:01 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Vitaly Mayatskikh <v.mayatskih@...il.com>
Cc:	Vivek Goyal <vgoyal@...hat.com>, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Randy Dunlap <rdunlap@...otime.net>
Subject: Re: [PATCH 0/5] kdump: extract log buffer and registers from	vmcore on NMI button pressing

Vitaly Mayatskikh <v.mayatskih@...il.com> writes:
>
> Obviously, this change doesn't help if 2nd kernel is not able to
> boot. But there are other problems, which may prevent vmcore to be
> captured. For example, machine has RAM > HDD and it may save vmcore
> only over network. If network fails (e.g., due to bugs in NIC drivers
> or NFS, what is not so rare), and dump capture environment is
> non-interactive, or it doesn't have development tools like `crash',
> there's no chance even to guess what has happened.

In this case you don't need NMI, sysrq or some /sys trigger
is good enough.

NMI would be only needed if the crash kernel is completely
hosed too.

> Other possibilities of failure may include broken RAID controller,
> HDD, RAM. NMI button in such situations is a last chance to see old
> log.

The big problem is that the NMI is used by more and more subsystems,
and several of them tend to eat all NMIs, so the leftovers are less and
less.  Overall I would not consider it reliable.

Also NMI buttons are not actually all that common.

I'm also not sure you really need the analysis in kernel space.

Why not have a user space program that does a quick analysis
of the previous vmcore and dumps a summary only?  In fact 
I suspect crash can already do that.

-Andi


-- 
ak@...ux.intel.com -- Speaking for myself only.
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ