Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp8564244ybn; Tue, 1 Oct 2019 09:52:58 -0700 (PDT) X-Google-Smtp-Source: APXvYqxhxo1MshjiAu3CfScKsC06Hbz8Pb47ca8zq52dyCnRZZYwVG4Qyp1obLlewUqY5Nezl1FI X-Received: by 2002:a17:906:164d:: with SMTP id n13mr12567024ejd.75.1569948778537; Tue, 01 Oct 2019 09:52:58 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569948778; cv=none; d=google.com; s=arc-20160816; b=CXflaEz77JZNamDLgfuXwuIaT0efjEmN03akIf3aZkQgIadlE+83sunWx6X5ZjYC/9 jCxr1/NlaQbtjvSvMjuxjOpkosBcRifF3d39JvKssClWhJ1rbK3d6pvMLuQ/DhiZK8sa X7PqGk76UE5XH3LqI6+7Oxcabtd8ORWg0KTt0+sjXSdigaNLWpvgTMhjEFamMoRPtVzJ mvHz7Slc2fFR13IhWFUf5DEhMw/52HIgC/nNo2PgGVx99xga1xgu0dyn+G1LI63yfELm j5hoEPKw2hDmdkvdE6TVyR8TpDpKq4kQJBmkITPwmUin94dOi5s+9lD+GTU74/xChDVc VNAg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=Lxp8oYaMNJyvXRtuq8ECTFUMZqEOnJsC/uXrAq5dMZc=; b=ndFWtod8so/HU7VDcZMwHiPZ6QY/uIBcxVnJ7gysKJT31spe5GaJxeDlq0gJ5bA4t9 aYNShv+qmxgReMX5j8LxuopMbHDvyYNoqYAxukjBYdOjTUHyNSsu87osaU1xl4udG+Hw 0nwIc5F7SU1gHk8+OC/tnwUv+D6tETDm1y2Jo5LESsK6xeFCcQDLKs53vuxRPFUcnJbF Y2Nt0hTWj02F85hUW7jW9SKZPpnf9YR1ddm2ESh//Cb6n31ARyKn36Y3wTmOJPa0qQBF 0dj8jftyC7mq0uMsfYYWxqMeXSc8gSqLgVl+j4vStseS3e3GbjMpBliNi4s/a/8IZ5M7 xTNA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j3si10952120edj.448.2019.10.01.09.52.33; Tue, 01 Oct 2019 09:52:58 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389874AbfJAQO4 (ORCPT + 99 others); Tue, 1 Oct 2019 12:14:56 -0400 Received: from foss.arm.com ([217.140.110.172]:53242 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1731663AbfJAQO4 (ORCPT ); Tue, 1 Oct 2019 12:14:56 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BB1E4337; Tue, 1 Oct 2019 09:14:55 -0700 (PDT) Received: from localhost (unknown [10.37.6.20]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 32F2F3F71A; Tue, 1 Oct 2019 09:14:55 -0700 (PDT) Date: Tue, 1 Oct 2019 17:14:53 +0100 From: Andrew Murray To: Russell King - ARM Linux admin Cc: Will Deacon , Masahiro Yamada , Arnd Bergmann , Catalin Marinas , Linux Kernel Mailing List , linux-arm-kernel , Linus Torvalds , Nicolas Saenz Julienne Subject: Re: [PATCH] Partially revert "compiler: enable CONFIG_OPTIMIZE_INLINING forcibly" Message-ID: <20191001161453.GO42880@e119886-lin.cambridge.arm.com> References: <20190930114540.27498-1-will@kernel.org> <20191001104253.fci7s3sn5ov3h56d@willie-the-truck> <20191001114129.GL42880@e119886-lin.cambridge.arm.com> <20191001143626.GI25745@shell.armlinux.org.uk> <20191001152826.GM42880@e119886-lin.cambridge.arm.com> <20191001154814.GJ25745@shell.armlinux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191001154814.GJ25745@shell.armlinux.org.uk> User-Agent: Mutt/1.10.1+81 (426a6c1) (2018-08-26) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 01, 2019 at 04:48:14PM +0100, Russell King - ARM Linux admin wrote: > On Tue, Oct 01, 2019 at 04:28:27PM +0100, Andrew Murray wrote: > > I hadn't noticed the use of __OPTIMIZE__ - indeed if __compiletime_assert > > is no-op'd and you reach it then you won't have a build error - but you > > may get uninitialised values instead. > > > > Presumably the purpose of __OPTIMIZE__ in this case is to prevent getting > > an undefined function error for the __compiletime_assert line, even though > > it doesn't get called (when using a compiler that doesn't optimize out the > > call to the unused function). > > > > Why is the call to __get_user_bad not guarded in this way for when > > __OPTIMIZE__ isn't set, i.e. why doesn't it suffer from the issue > > that the following fixes? > > Officially, the kernel does not support building with -O0. To start > with, the top level makefile has: > > ifdef CONFIG_CC_OPTIMIZE_FOR_SIZE > KBUILD_CFLAGS += -Os > else > KBUILD_CFLAGS += -O2 > endif > > and we've said for years that the kernel relies upon the compiler > optimiser to build correctly. You may be lucky if you pass it via > some method to 'make' but that's going to rely on the argument order > to the compiler, and the order in which the compiler processes its > arguments, and whether it (for example) correctly disables all > optimisations if it encounters -O0 somewhere. So in practice, __OPTIMIZE__ will likely always be set, as far as I can tell it's supported in GCC, Clang and Intel compilers. Though the exception to this is for crypto/jitterentropy.c where the -O0 flag is unconditionally set. Are there other exceptions to this in terms of compilers? Perhaps it may be possible to use BUILD_BUG after all. Thanks, Andrew Murray > > -- > RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ > FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up > According to speedtest.net: 11.9Mbps down 500kbps up