From: ebiederm@xmission.com (Eric W. Biederman)
To: "Magnus Damm" <magnus.damm@gmail.com>
Cc: "Magnus Damm" <magnus@valinux.co.jp>,
linux-kernel@vger.kernel.org, "Vivek Goyal" <vgoyal@in.ibm.com>,
"Andi Kleen" <ak@muc.de>,
fastboot@lists.osdl.org, Horms <horms@verge.net.au>,
"Dave Anderson" <anderson@redhat.com>
Subject: Re: [PATCH 02/02] Elf: Align elf notes properly
Date: Thu, 09 Nov 2006 22:09:26 -0700 [thread overview]
Message-ID: <m1irhnnb09.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <aec7e5c30611091952j6cd7988akc1671d269925bba9@mail.gmail.com> (Magnus Damm's message of "Fri, 10 Nov 2006 12:52:40 +0900")
"Magnus Damm" <magnus.damm@gmail.com> writes:
> I'm not sure you see all my points. The important parts are the
> offsets - offset 0 and offset N2 in the description above. The should
> be aligned somehow. Exactly how to align them depends on if the 64-bit
> spec is valid or not.
>
> My points are:
>
> - Some kdump code rounds up the size of "elf note header" today. This
> is unneccessary for 32 bit alignment and plain wrong for 64 bit
> alignment. So I think that the code is strange and should be changed
> regardless if the 64-bit spec is valid or not.
Sure that is reasonable, if correct.
> - Many implementations incorrectly calculate N2 as: roundup(sizeof(elf
> note header)) + roundup(n_namesz).
I am not certain that is incorrect. roundup(sizeof(elf note header), 4) +
roundup(n_namesize, 4) will yield something that is properly 4 byte aligned.
I do agree that implementation is not correct for 8 byte alignment. 8 byte
alignment does not appear to be in widespread use in the wild.
> - You say that the size of the notes do not vary and therefore this is
> a non-issue. I agree that the size does not vary, but I believe that
> the aligment _is_ an issue. One example is the N2 calculation above,
> but more importantly the vmcore code that merges the elf note sections
> into one. You know, if you have more than one cpu you will end up with
> more than one crash note. And if you run Xen you will have even more
> crash notes.
Sure that is clearly an issue.
> - On top of this I think it would be nice if all this code could be
> unified to avoid code duplication. But we need to straighten out this
> and agree on how the aligment should work before the code can be
> merged into one implementation.
Sure.
To verify your claim that 8 byte alignment is correct I checked the
core dump code in fs/binfmt_elf.c in the linux kernel. That always
uses 4 byte alignment. Therefore it appears clear that only doing
4 byte alignment is not a local misreading of the spec, and is used in
other implementations. If you can find an implementation that uses
8 byte alignment I am willing to consider it.
The current situation is that the linux kernel generated application
core dumps use 4 byte alignment so I expect that is what existing
applications such as gdb expect.
Therefore we use 4 byte alignment unless it can be shown that the
linux core dumps are a fluke and should be fixed.
Eric
next prev parent reply other threads:[~2006-11-10 5:11 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-02 10:19 [PATCH 01/02] Elf: Always define elf_addr_t in linux/elf.h Magnus Damm
2006-11-02 10:19 ` [PATCH 02/02] Elf: Align elf notes properly Magnus Damm
2006-11-09 14:00 ` Eric W. Biederman
2006-11-10 0:50 ` Horms
2006-11-10 4:00 ` Magnus Damm
2006-11-10 23:37 ` Jeremy Fitzhardinge
2006-11-10 23:39 ` David Miller
2006-11-11 0:26 ` Jeremy Fitzhardinge
2006-11-11 0:43 ` David Miller
2006-11-11 1:20 ` Jeremy Fitzhardinge
2006-11-13 2:16 ` Magnus Damm
2006-11-13 3:03 ` Eric W. Biederman
2006-11-13 0:23 ` Horms
2006-11-13 1:47 ` David Miller
2006-11-10 3:52 ` Magnus Damm
2006-11-10 5:09 ` Eric W. Biederman [this message]
2006-11-10 6:53 ` Magnus Damm
2006-11-10 14:49 ` Vivek Goyal
2006-11-10 16:04 ` Dave Anderson
2006-11-10 16:10 ` Eric W. Biederman
2006-11-10 23:39 ` Jeremy Fitzhardinge
2006-11-02 10:43 ` [PATCH 01/02] Elf: Always define elf_addr_t in linux/elf.h Jakub Jelinek
2006-11-02 10:51 ` Magnus Damm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m1irhnnb09.fsf@ebiederm.dsl.xmission.com \
--to=ebiederm@xmission.com \
--cc=ak@muc.de \
--cc=anderson@redhat.com \
--cc=fastboot@lists.osdl.org \
--cc=horms@verge.net.au \
--cc=linux-kernel@vger.kernel.org \
--cc=magnus.damm@gmail.com \
--cc=magnus@valinux.co.jp \
--cc=vgoyal@in.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox