[PATCH] kdump: Fix for machine checkstop on DMA fault

[Michael Ellerman]

On Thu, 2006-03-23 at 14:12 -0600, Olof Johansson wrote:
> On Thu, Mar 23, 2006 at 12:19:04AM -0600, Olof Johansson wrote:
> 
> > The crash kernel needs to be even more careful, and instead read out
> > the entries that are mapped and reserve them. This would require a bit
> > more plumbing since there's no way to read an entry right now, but it'd
> > remove that hole.
> 
> Actually, what's probably easier is to allocate some entries when the
> purgatory is set up, and make the crash kernel only use those by modifying
> the device tree accordingly. Sort of how regular memory is handled right
> now. That'd be a cleaner solution with less changes needed.
> 
> The trick will be to get a decent size contiguous allocation, but the
> same applies for the memory reserve.

I disagree. In most cases the kdump kernel will be loaded by the boot
scripts, so reserving TCE space then is ~= reserving it for the life of
the first kernel. Given that TCE space is a scarce commodity I don't
think reserving it in the first kernel is a viable option.

What we should do is modify the second kernel so that instead of
clearing the TCE tables it instead walks the tables and detects existing
mappings, and then marks those as reserved so they're not overwritten.

This should give us 100% safety from the second kernel reusing a mapping
and copping a rogue DMA, and doesn't inflict any penalty on the first
kernel. It does fall down if there's no TCE space left for a device when
the second kernel comes up, but I think that's the best trade off.

cheers

-- 
Michael Ellerman
IBM OzLabs

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20060327/4df6f95a/attachment.pgp>