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: <20101208144245.GB31703@redhat.com>
Date:	Wed, 8 Dec 2010 09:42:46 -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:20:05PM +0100, Peter Zijlstra wrote:
> On Wed, 2010-12-08 at 09:01 -0500, Don Zickus wrote:
> > On Wed, Dec 08, 2010 at 12:30:20AM +0100, Peter Zijlstra wrote:
> > > On Thu, 2010-12-02 at 11:15 -0500, Don Zickus wrote:
> > > 
> > > > Vivek suggested to me this morning that I should just blantantly disable the
> > > > perf counter during init when running my test. 
> > > 
> > > Nah, we should actively scan for that during the bring-up and kill
> > > hw-perf when we find an enable bit set, some BIOSes actively use the
> > > PMU, this is something that should be discouraged.
> > 
> > Ok, the reboot notifier addresses the kexec problem but doesn't fix it
> > though (I have to test to confirm that, comments below).  
> 
> 
> > The bios check
> > should catch those situations (ironically I stumbled upon a machine with
> > this problem, so I will test your patch with it, though it only uses perf
> > counter 0). 
> 
> Right, they usually only steal one or two counters, but the fact that
> they're using them at all is insane and should be punished.
> 
> >  The kdump problem will still exist, not sure if we care and
> > perhaps we should document in the changelog that we know kdump is still
> > broken (unless we do care).
> 
> You mean even if we cure the kexec reboot notifier patch thing kdump is
> still borken?
> 

Yes. reboot notifier notifications are not sent in kdump path. In this
path we know kernel has crashed and we just try to do bare minimal things
to boot into second kernel. If some hardware is left in inconsistent
state we try to recover from that situation by resetting the device
when second kernel is booting.

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.

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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ