Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752187AbcCGIuL (ORCPT ); Mon, 7 Mar 2016 03:50:11 -0500 Received: from mail-wm0-f68.google.com ([74.125.82.68]:35811 "EHLO mail-wm0-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752082AbcCGIt7 (ORCPT ); Mon, 7 Mar 2016 03:49:59 -0500 Date: Mon, 7 Mar 2016 09:49:54 +0100 From: Ingo Molnar To: Linus Torvalds Cc: Peter Zijlstra , Linux Kernel Mailing List , Thomas Gleixner , Dave Hansen , Peter Anvin , Dave Hansen , Andrew Morton , Helge Deller , Stephen Rothwell , "linux-tip-commits@vger.kernel.org" Subject: Re: [tip:mm/pkeys] mm/pkeys: Fix siginfo ABI breakage caused by new u64 field Message-ID: <20160307084954.GA19613@gmail.com> References: <20160301125451.02C7426D@viggo.jf.intel.com> <20160305135006.GA15928@gmail.com> <20160305165234.GY6356@twins.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2413 Lines: 54 * Linus Torvalds wrote: > On Sat, Mar 5, 2016 at 8:52 AM, Peter Zijlstra 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