netdev - Re: [PATCH] ehea: Add kdump support

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] [day] [month] [year] [list]

Date:	Tue, 27 Nov 2007 11:35:18 +1100
From:	Michael Neuling <mikey@...ling.org>
To:	Christoph Raisch <RAISCH@...ibm.com>
cc:	michael@...erman.id.au, Jan-Bernd Themann <THEMANN@...ibm.com>,
	Jeff Garzik <jeff@...zik.org>,
	linux-kernel <linux-kernel@...r.kernel.org>,
	linux-ppc <linuxppc-dev@...abs.org>,
	Marcus Eder <MEDER@...ibm.com>,
	netdev <netdev@...r.kernel.org>,
	Paul Mackerras <paulus@...ba.org>,
	Stefan Roscher <stefan.roscher@...ibm.com>,
	tklein@...ux.ibm.com
Subject: Re: [PATCH] ehea: Add kdump support 

In message <OF94123F44.9DB75CE9-ONC125739F.00398E63-C125739F.003B2AFE@...ibm.com> you wrote:
> Michael Ellerman wrote on 26.11.2007 09:16:28:
> > Solutions that might be better:
> >
> >  a) if there are a finite number of handles and we can predict their
> >     values, just delete them all in the kdump kernel before the driver
> >     loads.
> 
> Guessing the values does not work, because of the handle structure
> defined by the hypervisor.
> 
> >  b) if there are a small & finite number of handles, save their values
> >     in a device tree property and have the kdump kernel read them and
> >     delete them before the driver loads.
> 
> 5*16*nr_ports+1+1=   >82. a ML16 has 4 adapters with up to 16 ports, so the
> number is not small anymore....

I assume this machine with a huge number of adapters has a huge amount
of memory too! :-)

> The device tree functions are currently not exported.

We can add this.

> If you crashdump to a new kernel, will it get the device tree
> representation of the crashed kernel or of the initial one of open
> firmware?

The kexec tools userspace control this.  Normally it just takes the
current device tree plus some modifications (eg. initrd location
changes).

So provided the ehea driver export this info somewhere, it can be
grabbed by the kexec tools and stuffed in the device tree of the new
kernel.  

That being said, the proper place to have this would be original device
tree.

> 
> >  c) if neither of those work, provide a minimal routine that _only_
> >     deletes the handles in the crashed kernel.
> 
> I would hope this has the highest chance to actually work.
> For this we would have to add a proper notifier chain.
> Do you agree?
> 
> >  d) <something else>
> 
> Firmware change? But that's not something you will get very soon.
> 
> Christoph R.
> 
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html