Re: [tip:mm/pkeys] mm/pkeys: Fix siginfo ABI breakage caused by new u64 field

[Ingo Molnar]

* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Sat, Mar 5, 2016 at 8:52 AM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> 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