From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: "xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
Simon Horman <horms@verge.net.au>,
Keir Fraser <keir.xen@gmail.com>
Subject: Re: Unaligned writes on the kexec path
Date: Tue, 29 Nov 2011 12:54:09 +0000 [thread overview]
Message-ID: <4ED4D5F1.2080000@citrix.com> (raw)
In-Reply-To: <4ED4D1A90200007800064095@nat28.tlf.novell.com>
On 29/11/11 11:35, Jan Beulich wrote:
>>>> On 29.11.11 at 11:49, Andrew Cooper <andrew.cooper3@citrix.com> wrote:
>> On 29/11/11 05:51, Simon Horman wrote:
>>> Hi Keir, Hi Andrew,
>>>
>>> On Mon, Nov 28, 2011 at 08:42:16PM +0000, Keir Fraser wrote:
>>>> On 28/11/2011 14:24, "Andrew Cooper" <andrew.cooper3@citrix.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> In c/s 7493bb48d89f, you change the internals of kexec_crash_save_info()
>>>> The patch is by Simon Horman, cc'ed, not me.
>> Right. Sorry. I should have remembered that basing "who wrote the
>> patch" on a simple hg log was not a safe bet.
> I don't think there's much room for improvement - all members of
> crash_xen_info_t are of "unsigned long" type, but ELF note handling
> will only ever guarantee 4-byte alignment.
>
> Jan
>
Depending on how flexible we want to be, we can either specify that the
name field should be 2n words long plus 1-4 bytes, which will cause it
to align to an odd number of 4 bytes, which will cause the desc field to
be aligned to 8 bytes when the type field in the note header is taken
into account. Then, the desc field should be constrained to be (2n+1) +
1-4bytes which would cause it to have 8 byte alignment, and subsequently
8 byte align the next note.
Alternatively, we could artificially extend the name up to an odd 4 byte
alignment, and desc field up to 8 byte alignment with trailing \0's and
include this as part of their length fields. All names should be
processed as Null terminating strings (which wont suffer from having
extra Nulls at the end) and I have yet to see processing of a note which
doesn't take the buffer and cast it to a structure pointer. This also
wont suffer from from trailing data.
Then again, this does sound like quite a lot of work for not a lot, and
there is no guarantee that we wont break some of the more special code
which works with elf files in 'special' ways.
(What really should have happened was for ELF64 to specify 64bit
alignment of things like this, but we live and learn)
--
Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer
T: +44 (0)1223 225 900, http://www.citrix.com
next prev parent reply other threads:[~2011-11-29 12:54 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-11-28 14:24 Unaligned writes on the kexec path Andrew Cooper
2011-11-28 20:42 ` Keir Fraser
2011-11-29 5:51 ` Simon Horman
2011-11-29 10:49 ` Andrew Cooper
2011-11-29 11:35 ` Jan Beulich
2011-11-29 12:54 ` Andrew Cooper [this message]
2011-12-01 3:00 ` Simon Horman
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=4ED4D5F1.2080000@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=JBeulich@suse.com \
--cc=horms@verge.net.au \
--cc=keir.xen@gmail.com \
--cc=xen-devel@lists.xensource.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.