From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752884AbcKBMOP (ORCPT <rfc822;w@1wt.eu>);
        Wed, 2 Nov 2016 08:14:15 -0400
Received: from mx2.suse.de ([195.135.220.15]:50361 "EHLO mx2.suse.de"
        rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
        id S1751284AbcKBMON (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 2 Nov 2016 08:14:13 -0400
Date: Wed, 2 Nov 2016 13:14:09 +0100 (CET)
From: Richard Biener <rguenther@suse.de>
To: Markus Trippelsdorf <markus@trippelsdorf.de>
cc: Peter Zijlstra <peterz@infradead.org>,
        "Luis R. Rodriguez" <mcgrof@kernel.org>,
        Vegard Nossum <vegard.nossum@oracle.com>, Jiri Slaby <jslaby@suse.cz>,
        linux-kernel@vger.kernel.org,
        Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Linus Torvalds <torvalds@linux-foundation.org>, stable@vger.kernel.org,
        Ming Lei <ming.lei@canonical.com>,
        Steven Rostedt <srostedt@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>,
        Josh Poimboeuf <jpoimboe@redhat.com>,
        Cesar Eduardo Barros <cesarb@cesarb.eti.br>,
        Michael Matz <matz@suse.de>, David Miller <davem@davemloft.net>,
        Guenter Roeck <linux@roeck-us.net>,
        Fengguang Wu <fengguang.wu@intel.com>, Borislav Petkov <bp@alien8.de>,
        Boris Ostrovsky <boris.ostrovsky@oracle.com>,
        Juergen Gross <jgross@suse.com>, Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH 01/12] extarray: define helpers for arrays defined in
 linker scripts
In-Reply-To: <20161102121158.GA11638@x4>
Message-ID: <alpine.LSU.2.11.1611021313580.5294@t29.fhfr.qr>
References: <186f8242-3f8d-31cd-a8e8-9743bbc1c1fd@suse.cz> <20161017090930.GT3142@twins.programming.kicks-ass.net> <55e00c01-2da8-8d06-1d05-9ebf775736ec@oracle.com> <20161017114517.GQ3117@twins.programming.kicks-ass.net> <55b3cbe0-f8fc-6505-411d-5f050d3414cc@oracle.com>
 <20161018211803.GV8651@wotan.suse.de> <alpine.LSU.2.11.1610190949310.2258@t29.fhfr.qr> <20161019091347.GE3102@twins.programming.kicks-ass.net> <alpine.LSU.2.11.1610191131250.2258@t29.fhfr.qr> <20161019102555.GJ3102@twins.programming.kicks-ass.net>
 <20161102121158.GA11638@x4>
User-Agent: Alpine 2.11 (LSU 23 2013-08-11)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 2 Nov 2016, Markus Trippelsdorf wrote:

> On 2016.10.19 at 12:25 +0200, Peter Zijlstra wrote:
> > On Wed, Oct 19, 2016 at 11:33:41AM +0200, Richard Biener wrote:
> > > On Wed, 19 Oct 2016, Peter Zijlstra wrote:
> > 
> > > > This is also an entirely different class of optimizations than the whole
> > > > pointer arithmetic is only valid inside an object thing.
> > > 
> > > Yes, it is not related to that.  I've opened 
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78035 to track an
> > > inconsistency in that new optimization.
> > > 
> > > > The kernel very much relies on unbounded pointer arithmetic, including
> > > > overflow. Sure, C language says its UB, but we know our memory layout,
> > > > and it would be very helpful if we could define it.
> > > 
> > > It's well-defined and correctly handled if you do the arithmetic
> > > in uintptr_t.  No need for knobs.
> > 
> > So why not extend that to the pointers themselves and be done with it?
> > 
> > In any case, so you're saying our:
> > 
> > #define RELOC_HIDE(ptr, off)						\
> > ({									\
> > 	unsigned long __ptr;						\
> > 	__asm__ ("" : "=r"(__ptr) : "0"(ptr));				\
> > 	(typeof(ptr)) (__ptr + (off));					\
> > })
> > 
> > could be written like:
> > 
> > #define RELOC_HIDE(ptr, off)			\
> > ({						\
> > 	uintptr_t __ptr = (ptr);		\
> > 	(typeof(ptr)) (__ptr + (off));		\
> > })
> > 
> > Without laundering it through inline asm?
> > 
> > Is there any advantage to doing so?
> > 
> > But this still means we need to be aware of this and use these macros to
> > launder our pointers.
> > 
> > Which gets us back to the issue that started this whole thread. We have
> > code that now gets miscompiled, silently.
> > 
> > That is a bad situation. So we need to either avoid the miscompilation,
> > or make it verbose.
> 
> FYI this issue was fixed on gcc trunk by:
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=76bc343a2f1aa540e3f5c60e542586bb1ca0e032

Note while this change restored the old behavior this change was _not_
intended to fix this particular fallout (it was to fix an inconsistency
with respect to comparing addresses of symbols that can be interposed).
It just happens that your externs can be interposed with ELF.

Richard.