lkml.org 
[lkml]   [2013]   [Mar]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH v3 17/21] vmcore: check NT_VMCORE_PAD as a mark indicating the end of ELF note buffer
HATAYAMA Daisuke <d.hatayama@jp.fujitsu.com> writes:

> From: "Eric W. Biederman" <ebiederm@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@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


\
 
 \ /
  Last update: 2013-03-21 05:41    [W:0.082 / U:0.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site