linux-kernel - Re: [PATCH 1/7] ia64, kdump: Mask MCA/INIT on freezing cpus

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: <20090624111415.GA6878@sgi.com>
Date:	Wed, 24 Jun 2009 06:14:15 -0500
From:	Robin Holt <holt@....com>
To:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
Cc:	Robin Holt <holt@....com>, linux-ia64@...r.kernel.org,
	linux-kernel@...r.kernel.org, Vivek Goyal <vgoyal@...hat.com>,
	Haren Myneni <hbabu@...ibm.com>, kexec@...ts.infradead.org
Subject: Re: [PATCH 1/7] ia64, kdump: Mask MCA/INIT on freezing cpus

On Tue, Jun 23, 2009 at 05:07:14PM +0900, Hidetoshi Seto wrote:
> Robin Holt wrote:
> > On Tue, Jun 23, 2009 at 09:33:46AM +0900, Hidetoshi Seto wrote:
> >> Robin Holt wrote:
> > ...
> >> Do you mean that the 2nd kernel should be able to handle MCA/INIT from its
> >> boot up?  I guess the word PROM is nearly equal to PAL/SAL firmware, if so
> >> then I don't think there are good generic interface/procedure could be
> >> useful here.  Do you have any concrete idea?
> > 
> > No concrete ideas.  Just a really uneasy feeling whenever the INIT
> > is disabled.
> 
> Don't worry, don't be afraid.
> Again, my patches don't disable INIT until kdump is invoked.
> (And if kdump is invoked via INIT, it have already masked at the begging
>  of INIT handlers.)

The concern is that any time we prevent SAL from receiving control during
an MCA/INIT, we reduce the maintainability of the machine.  Having them
masked at any time results in the NMI/INIT not recording the PROM record
which we use to diagnose where the hang is.

In other patches, you implemented a do-nothing handler.  Could that
be used?

Alternatively, when the machine is first booted, the handler is defined
by SAL as a SAL routine.  Could you record that during kernel boot and
then just set the handler back to the SAL provided one prior to starting
the kexec kernel boot?  At that point, the machine is more like the
first boot.  Now that I think about this, this alternative seems fairly
attractive.

Thanks,
Robin
--
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/