linux-kernel - Re: perf hw in kexeced kernel broken in tip

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:	Wed, 8 Dec 2010 10:02:43 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Don Zickus <dzickus@...hat.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Yinghai Lu <yinghai@...nel.org>, Ingo Molnar <mingo@...e.hu>,
	Jason Wessel <jason.wessel@...driver.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Haren Myneni <hbabu@...ibm.com>
Subject: Re: perf hw  in kexeced kernel broken in tip

On Wed, Dec 08, 2010 at 03:48:04PM +0100, Peter Zijlstra wrote:
> On Wed, 2010-12-08 at 09:42 -0500, Vivek Goyal wrote:
> > 
> > Either driver itself can detect that device is in inconsistent state and
> > reset it otherwise we also pass a command line parameter "reset_devices" to
> > second kernel to explicitly tell kernel that devices might be in bad state,
> > reset these during initialization. If we want to use these perf counters in
> > kdump kernel, we shall have to do something similar.
> 
> Right, so I'm perfectly fine with leaving the kdump kernel broken for
> now and if people really do need hardware events we can try and reset
> the hardware when we find that reset_devices command line parameter.
> 
> Not sure how that interacts with these broken BIOSes,

reset_devices was meant to be dual purpose so that it can handle broken
BIOSes also. So if BIOS is broken then one can pass "reset_devices" to 
kernel and driver can attempt to reset the device and boot the kernel.

>but its kdump so
> its mostly broken by design anyway ;-)

Kdump has its share of problems especially with the fact that
kernel/drivers find devices in bad state and are not hardened enough
to deal with that. But on bare metal what's the better way of capturing
kernel crash dump? Trying to do anything post crash in the kernel is
also not very reliable either.

I think the way we fix kernel for boot problems on newer hardware, for broken
BIOses, we need to keep on fixing it in kdump path also to make sure new
devices/drivers can cope up with this scenario. 

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/