[PATCH] makedumpfile: memset() in cyclic bitmap initialization introduce segment fault

[HATAYAMA Daisuke]

(2013/12/20 11:17), Dave Young wrote:
>> Also, I'm interested in the memory map passed to from EFI in that
>>
>>> cat /proc/iomem:
>>> 00000000-00000fff : reserved
>>> 00001000-0009ffff : System RAM
>>> 000a0000-000bffff : PCI Bus 0000:00
>>> 000f0000-000fffff : System ROM
>>> 00100000-3d162017 : System RAM
>>>    01000000-015cab9b : Kernel code
>>>    015cab9c-019beb3f : Kernel data
>>>    01b4f000-01da9fff : Kernel bss
>>>    30000000-37ffffff : Crash kernel
>>> 3d162018-3d171e57 : System RAM
>>> 3d171e58-3d172017 : System RAM
>>> 3d172018-3d17ae57 : System RAM
>>> 3d17ae58-3dc10fff : System RAM
>>
>> this part is consecutive but somehow is divided into 4 entries.
>> You called your environment as ``EFI virtual machine'', could you tell
>> me precisely what it mean? qemu/KVM or VMware guest system? I do want
>> to understand how this kind of memory map was created. I think this
>> kind of memory mapping is odd and I guess this is caused by the fact
>> that the system is a virtual environment.
>
> This is not specific to EFI machine, it's the reserved setup_data regions
> They happened to be continous but they do not have to be continuous.
>

Thanks for pointing out that. I've just read Documentation/x86/boot.txt
and parse_setup_data().

But I don't understand well why these regions are divided as these.
I guess kernel divides the System RAM this way and the memory map first
passed to by EFI is all page aligned, right?

Also, looking at parse_setup_data(), currently handled data in setup_data
interface is extended e820 entries and dtb case only.

                 switch (data_type) {
                 case SETUP_E820_EXT:
                         parse_e820_ext(pa_data, data_len);
                         break;
                 case SETUP_DTB:
                         add_dtb(pa_data);
                         break;
                 default:
                         break;
                 }

Is it right that this kind of memory map doesn't occur as long as either
of information is passed to via setup_data? IOW, is this necessary
information?

>>
>> And for Vivek, this case is a concrete example of multiple RAM entries
>> appearing in a single page I suspected in the mmap failure patch,
>> although these entries are consecutive in physical address and can be
>> represented by a single entry by merging them in a single entry. But
>> then it seems to me that there could be more odd case that multiple
>> RAM entries but not consecutive. I again think this should be addressed
>> in the patch for the mmap failure issue. How do you think?
>
> They are different problems, the previous mmap bug is for cross page regions
> with different page flags.
>

I understand that. What I think problem here is the case where multiple
System RAM entries appear in a single page. In the above memory map, they
are 3d171000, 3d172000 and 3d17a000. My fixing patch is to copy fractional
pages in the 2nd kernel in order to make it possible to mmap without affecting
non-System RAM area as much as possible, and then if there is this kind of
System RAM entries, we need to use the same page in the 2nd kernel for
different System RAM entries that shares the same page in the 1st kernel. This
needs a little additional processing and we want to keep implementation as
simple as possible as long as there's no such system in real world. However,
I'm surprised to see the memory mapping above.

-- 
Thanks.
HATAYAMA, Daisuke