[PATCH v3 17/21] vmcore: check NT_VMCORE_PAD as a mark indicating the end of ELF note buffer
Eric W. Biederman
ebiederm at xmission.com
Wed Mar 20 23:54:25 EDT 2013
HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> writes:
> From: "Eric W. Biederman" <ebiederm at xmission.com>
> Subject: Re: [PATCH v3 17/21] vmcore: check NT_VMCORE_PAD as a mark indicating the end of ELF note buffer
> Date: Tue, 19 Mar 2013 14:11:51 -0700
>
>> HATAYAMA Daisuke <d.hatayama at jp.fujitsu.com> writes:
>>
>>> Modern kernel marks the end of ELF note buffer with NT_VMCORE_PAD type
>>> note in order to make the buffer satisfy mmap()'s page-size boundary
>>> requirement. This patch makes finishing reading each buffer if the
>>> note type now being read is NT_VMCORE_PAD type.
>>
>> Ick. Even with a pad header you can mark the end with an empty header,
>> and my memory may be deceiving me but I believe an empty header is
>> specified by the ELF ABI docs.
>>
>> Beyond which I don't quite see the point of any of this as all of these
>> headers need to be combined into a single note section before being
>> presented to user space.
>
> Though this patch might get unecessary later, I cannot find part
> explaining necessity of marking end of ELF segmetns with an empty
> header in ELF spec. For example:
You are right. It appears to be our own invention and just part of
the ABI of taking a crash dump. Something we should sit down and
document someday.
> Also, it's possible to get size of a whole part of ELF note segments
> from p_memsz or p_filesz, and gdb and binutils are reading the note
> segments until reaching the size.
Agreed. Except in our weird case where we generate the notes on the
fly, and generate the NOTE segment header much earlier.
Eric
More information about the kexec
mailing list