[PATCH] kdump, x86: Process multiple Crash kernel in /proc/iomem
Yinghai Lu
yinghai at kernel.org
Fri Mar 22 17:35:28 EDT 2013
On Fri, Mar 22, 2013 at 2:27 PM, H. Peter Anvin <hpa at zytor.com> wrote:
> On 03/22/2013 02:21 PM, Vivek Goyal wrote:
>>
>> BTW, I had a query about loading 64bit entry point bzImage. In 32bit
>> bzImage entry point logic, we used to load bzImage at the beginning
>> of memory hole and initrd at the end of memory hole. So that bzImage
>> and initramfs are as far as possible and initramfs decompression does
>> not overwrite anything or for that matter setting bss are does not
>> spill over into initramfs.
>>
>> In new code, It looks like we seem to be loading kernel towards the end
>> of the hole.
>>
>> addr = add_buffer(info, kernel + kern16_size, k_size,
>> size, align, 0x100000, -1, -1);
>>
>> IIUC, this has potential that new kernel can overwrite some of the old
>> kernel's data structure while setting up bss. Shouldn't we do it 32bit
>> entry code way where bzImage is loaded towards the beginning of hole and
>> initramfs is loaded towards the end of the hole.
>>
>
> Since boot protocol 2.10+ the kernel actively exports how much memory it
> needs during its setup phase.
>
yes, we got that size that kernel needed from hdr. more lines from the new code.
/* need to use run-time size for buffer searching */
dbgprintf("kernel init_size 0x%x\n", real_mode->init_size);
size = _ALIGN(real_mode->init_size, 4096);
align = real_mode->kernel_alignment;
More information about the kexec
mailing list