[RFC] Old paca being written by firmware after kexec

[Michael Ellerman]

Hi,

I'm seeing a bug of sorts when I kexec some kernels. It's exhibiting as page 
structs being corrupted early during boot:

freeing bootmem node 0
Bad page state at __free_pages_ok (in process 'swapper', page 
c0000000005a7408)
flags:0x0000000000020004 mapping:0000000000000000 mapcount:0 count:0
Backtrace:
Call Trace:
[c00000000257bc00] [c000000002089c54] .bad_page+0x90/0xec (unreliable)
[c00000000257bc80] [c00000000208a26c] .__free_pages_ok+0x170/0x174
[c00000000257bd50] [c0000000025385e8] .free_all_bootmem_core+0x3e8/0x404
[c00000000257be30] [c000000002534188] .mem_init+0xe0/0x1d8
[c00000000257bed0] [c00000000252082c] .start_kernel+0x1f8/0x328
[c00000000257bf90] [c000000002008684] .hmt_init+0x0/0x7c
Trying to fix it up, but a reboot is needed

What's happening is that firmware is writing into the lppaca of the old 
kernel, which is now being used by the second kernel for page structs.

It seems to be writing into the word starting at paca[x].lppaca.reserved2, 
which I guess it's allowed to do seeing as it's reserved.

For kdump this isn't an issue, as the second kernel doesn't reuse the first 
kernel's memory.

But for regular kexec it can be a problem. I think we're getting away with it 
most of the time because a) if you kexec the same kernel then the paca will 
land in the same spot, b) it only seems to write into those locations for a 
short while early during boot (presumably until we've set up pointers to the 
new paca?).

The only solution I can see is to always allocate the paca in the same place. 
So that a kexec from one kernel to another always results in the paca landing 
in the same spot.

Any other ideas?

cheers

-- 
Michael Ellerman
IBM OzLabs

email: michael:ellerman.id.au
inmsg: mpe:jabber.org
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: not available
Url : http://ozlabs.org/pipermail/linuxppc64-dev/attachments/20051007/ea234682/attachment.pgp