[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20160307084954.GA19613@gmail.com>
Date: Mon, 7 Mar 2016 09:49:54 +0100
From: Ingo Molnar <mingo@...nel.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: Peter Zijlstra <peterz@...radead.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>,
Dave Hansen <dave.hansen@...ux.intel.com>,
Peter Anvin <hpa@...or.com>, Dave Hansen <dave@...1.net>,
Andrew Morton <akpm@...ux-foundation.org>,
Helge Deller <deller@....de>,
Stephen Rothwell <sfr@...b.auug.org.au>,
"linux-tip-commits@...r.kernel.org"
<linux-tip-commits@...r.kernel.org>
Subject: Re: [tip:mm/pkeys] mm/pkeys: Fix siginfo ABI breakage caused by new
u64 field
* Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Sat, Mar 5, 2016 at 8:52 AM, Peter Zijlstra <peterz@...radead.org> wrote:
> > On Sat, Mar 05, 2016 at 02:50:06PM +0100, Ingo Molnar wrote:
> >> A more workable method would be to have a test .c file that includes all UAPI
> >> structures in existence and defines a variable out of every single one, and then
> >> generates a list of sizeof() values or so. But even that isn't perfect: a
> >> structure might shift some fields forward, into a pre-existing hole, without
> >> changing the sizeof? We'd need a list of all field offsets in all structures to be
> >> really sure, and that's nasty.
> >
> > pahole has such logic, right?
>
> sparse could be taught to warn about unaligned u64's, but there are
> still config issues and issues across other architectures, and if some
> case gets missed it can be really quite painful.
So I think what might work is to define bitness and alignment-independent ABI
structures, and add (tooling) infrastructure to enforce that invariance.
For example every ABI detail in include/uapi/linux/perf_event.h is supposed to be
alignment-independent: it should be the same structure and same fields on all
32-bit and 64-bit platforms, regardless of the natural alignment of u64.
It's as close to an 'architecture independent' ABI as we can get IMHO. (With the
notable exception of endianness: making endianness an invariant via dynamic
endianness flags or so would be a mistake IMHO - structures that can be
transmitted between different machines via network or via disk should pick one
particular endianness statically and stick with that.)
If we can build tooling that checks _that_ kind of struct/ABI invariance, it would
be a lot easier to ensure that future changes don't break the ABI.
New structures could be annotated to be arch-invariant, via something like:
struct foo __arch_invariant_ABI {
...
};
and tooling could pick it up from there.
We do have a healthy body of 'messy' ABIs, which make liberal use of longs,
unaligned u64's and other non-invariant constructs - those would have to be
cleaned up and in the worst case they would have to be split into several explicit
variants.
I tried to do something like that with a particularly messy x86 header lately, see
arch/x86/include/uapi/asm/sigcontext.h, but it's a pretty slow and painful process
altogether...
Thanks,
Ingo
Powered by blists - more mailing lists