From: Dave Hansen <dave@sr71.net>
To: Ingo Molnar <mingo@kernel.org>, Stephen Rothwell <sfr@canb.auug.org.au>
Cc: "H. Peter Anvin" <hpa@zytor.com>,
linux-kernel@vger.kernel.org, dave.hansen@linux.intel.com,
akpm@linux-foundation.org, tglx@linutronix.de, mingo@elte.hu,
peterz@infradead.org, linux-next@vger.kernel.org, deller@gmx.de
Subject: Re: [PATCH] x86, pkeys: fix siginfo ABI breakage from new field
Date: Sat, 27 Feb 2016 11:16:44 -0800 [thread overview]
Message-ID: <56D1F61C.5050308@sr71.net> (raw)
In-Reply-To: <20160227114154.GA16200@gmail.com>
On 02/27/2016 03:41 AM, Ingo Molnar wrote:
> * Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>> > On Fri, 26 Feb 2016 09:44:00 -0800 "H. Peter Anvin" <hpa@zytor.com> wrote:
>>> > > __u64 is okay, "unsigned long" is really messy in the presence of 32-on-64 bit ABIs...
>> >
>> > Yeah, but unfortunately, any 64 bit scalar type here will change the
>> > alignment of the enclosing unions on (some) 32 bit platforms and thus
>> > break the ABI.
> Then a different solution has to be found.
I've acked Stephen's initial patch changing the 'u64' to an 'int'. x86
only needs 4 bits, and in the remote chance that a future implementation
needed more space, we could easily add a second 32-bit field "_pkey_hi"
or something that wouldn't have the alignment issues of a true 64-bit type.
How should we get Stephen's patch in to the tip tree?
next prev parent reply other threads:[~2016-02-27 19:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 17:34 [PATCH] x86, pkeys: fix siginfo ABI breakage from new field Dave Hansen
2016-02-26 17:44 ` H. Peter Anvin
2016-02-26 22:10 ` Stephen Rothwell
2016-02-27 11:41 ` Ingo Molnar
2016-02-27 19:16 ` Dave Hansen [this message]
2016-02-27 19:35 ` H. Peter Anvin
2016-02-27 23:26 ` Stephen Rothwell
2016-02-27 23:40 ` [PATCH v2] signals, pkeys: make si_pkey 32 bits Stephen Rothwell
2016-02-29 7:57 ` Ingo Molnar
2016-02-29 8:01 ` [PATCH] x86, pkeys: fix siginfo ABI breakage from new field Ingo Molnar
2016-02-29 22:54 ` Stephen Rothwell
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=56D1F61C.5050308@sr71.net \
--to=dave@sr71.net \
--cc=akpm@linux-foundation.org \
--cc=dave.hansen@linux.intel.com \
--cc=deller@gmx.de \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=sfr@canb.auug.org.au \
--cc=tglx@linutronix.de \
/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.