From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S964916AbcJQLpb (ORCPT ); Mon, 17 Oct 2016 07:45:31 -0400 Received: from merlin.infradead.org ([205.233.59.134]:52386 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933132AbcJQLpX (ORCPT ); Mon, 17 Oct 2016 07:45:23 -0400 Date: Mon, 17 Oct 2016 13:45:17 +0200 From: Peter Zijlstra To: Vegard Nossum Cc: Jiri Slaby , linux-kernel@vger.kernel.org, Greg Kroah-Hartman , Linus Torvalds , "Luis R . Rodriguez" , stable@vger.kernel.org, Ming Lei , Steven Rostedt Subject: Re: [PATCH 01/12] extarray: define helpers for arrays defined in linker scripts Message-ID: <20161017114517.GQ3117@twins.programming.kicks-ass.net> References: <20161016151616.31451-1-vegard.nossum@oracle.com> <20161016151616.31451-2-vegard.nossum@oracle.com> <20161017083315.GA29322@worktop.vlan200.pylonone.local> <186f8242-3f8d-31cd-a8e8-9743bbc1c1fd@suse.cz> <20161017090930.GT3142@twins.programming.kicks-ass.net> <55e00c01-2da8-8d06-1d05-9ebf775736ec@oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <55e00c01-2da8-8d06-1d05-9ebf775736ec@oracle.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Oct 17, 2016 at 01:27:08PM +0200, Vegard Nossum wrote: > On 10/17/2016 11:09 AM, Peter Zijlstra wrote: > >On Mon, Oct 17, 2016 at 11:01:13AM +0200, Jiri Slaby wrote: > >>On the top of that, it's incorrect C according to the standard. > > > >According to the standard non of the kernel has any chance in hell of > >working, so don't pretend you care about that :-) > > I think that's a bit of a false dilemma. It's obviously true that kernel > code does not conform to the standards, but that doesn't mean it's not > something we should strive towards or care about in general. It helps > static analysis tools, compiler diversity, etc. Sure, but this, two separately allocated objects their address should not be compared and therefore... stuff is explicitly relied upon by the kernel in many places. We have workarounds in various places, and this patch adds yet another instance of it. The workaround is simply confusing the compiler enough to have it not do the 'optimization'. But we very much still rely on this 'undefined' behaviour. I think it makes more sense to explicitly allow it than to obfuscate our code and run the risk a future compiler will see through our tricks. I don't see how its different than explicitly disabling the strict-aliasing muck, explicitly allowing (and 'defining') signed and pointer overflow, doing all the concurrency stuff on our own (gnu89 emphatically does _not_ have a memory model) etc.. And given GCC7 is still in development, this might be a good time to get a knob added for our benefit. Are we 'modifying' the C language, sure, but that ship has sailed long ago.