Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4052008pxb; Tue, 26 Jan 2021 11:04:58 -0800 (PST) X-Google-Smtp-Source: ABdhPJz032hWQ3tqSkUCEyARD87KN+TuXHHq+Vd5XnZ1Ai4H8t27XUaKBNSNqvFjwYC++YSCop48 X-Received: by 2002:a17:906:2c0e:: with SMTP id e14mr4236332ejh.299.1611687897815; Tue, 26 Jan 2021 11:04:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611687897; cv=none; d=google.com; s=arc-20160816; b=Iy6fXZ7V8nkdDLfEPus9N3CRC1pdkkEQ81bhtATkhzZho7cqJCUQYjhDN730Vb8AcT ZuBhx637yEWwArOErwpMbhc891x0c22zX/o2NoaxN3F5kcihrNC3WIYDtpf776nUPFhA NBPAgHxmubiPGaKviRFWNL7BA6BV2S0zKqUyLDxIzFSFj6Kki9eVHLbwj9tIxoR3fpnv oVvnM5oI+VZdkGYlbuEcL65f9jNrxkjBaqook3BvTzB/8IlNV5CKqukRfd0U/YFfA/Ts 0m6aTJqmoXYp/NnkMySAne9EcCiC099eYBLbf5+L9/BlW8qcHrTG0mcezXUMJhT9KEue 0Q0A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature :dkim-signature; bh=VKiELK44/clfmPnkaIaZL4Nw3WJm8IoUYvNKtK5zkDM=; b=BdhjeJZ1NPvwnvdCpKlz9p0tNDEPZhh/1OHnBGYLSVW80IInKqw9TF2znbnR8BFgX9 rmTVKHGDF14xzHOnDd1OuOg+oMvklMZj7wdQ2oA0JX0Bxk19Z6bee+L6w/9nlrA9U2cs a8iXUAJHrv+t0p2CSccnYN/0swe6Qhyaa54XNs5e0ajh+CJSA3aibEMikfGSZO5Nxczd 1dZVpPbW9NjZdJj4np5BdlwWpjuYqET1Jb3YDirq8MMIt7tYCgJ1gfxinJvr7OaOKaJ/ hOe16ENKqa+zGB3G+8IY4c6NYEcGcCn+Fm3kPggj/8RN3hkr+47nvGCS7nB6Aco096QY MFTA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kroah.com header.s=fm2 header.b=lxj2Iicf; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=NFrD6SIq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id o27si9625043edz.400.2021.01.26.11.04.32; Tue, 26 Jan 2021 11:04:57 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kroah.com header.s=fm2 header.b=lxj2Iicf; dkim=pass header.i=@messagingengine.com header.s=fm1 header.b=NFrD6SIq; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2405528AbhAZNw0 (ORCPT + 99 others); Tue, 26 Jan 2021 08:52:26 -0500 Received: from out4-smtp.messagingengine.com ([66.111.4.28]:42721 "EHLO out4-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2405000AbhAZNwV (ORCPT ); Tue, 26 Jan 2021 08:52:21 -0500 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id BBD105C0114; Tue, 26 Jan 2021 08:51:31 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Tue, 26 Jan 2021 08:51:31 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kroah.com; h= date:from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=fm2; bh=VKiELK44/clfmPnkaIaZL4Nw3WJ m8IoUYvNKtK5zkDM=; b=lxj2Iicf5HYw5jsMZHILmC1AdXAc8psIN6EGe49AINU AkPzShEEOPU4dPsRYvHkTR12UIQ5C7/BSY5Asmv778Um34rNXkCTeB3ooEj4CVpJ QXdusUrJunHKxaaViPKkFEaWOtw4ME/JSQyfydbmwUEFaj1+3Frn2G17rSv1kL3B 7vOTH/teNwHK+9OSez3qhvbcNv4CUhUthGZdfWyRUkvVUzvRrvvK4n9vuMr+Fo/x hPQgPioyDUqe2SSzrkSBOxiA5y8jnpbAJRjp2lzx0Gnj7q0yv9QNCiamx02lGQzr DLNv2IejI10E9wa15ol95Y1IwVdCTdBoi55hnklup2Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=VKiELK 44/clfmPnkaIaZL4Nw3WJm8IoUYvNKtK5zkDM=; b=NFrD6SIqFfPIwvf9YMFyQp Mv9mubkf64Er0dqpA83l1j63Co2IaZOE8/864vEHE9Jbr3CziUp+vImv77VCZ/rC akNGSCy/DnTGhvy8xWL/9wQga7ATsMzoRZ/xg0Qld1hXudjCKPxZtBuVkFG9PxuD JWSlEOcZvzf7Zb87nqCeVRsKOeCZ72ALITQBr0Vk17HXx31KEFEGt+0a/T3mVf3g sOgVhi91k3dKQEsPPZehVsE6zzj9xw6s2deSqpCWkjhW86RhNfKlcwdWvbQBfd1N y3PnS4PB9RuqSiULqGpkus1W0DMmHjF3bkHiWFnFmNmxFvWxALZ2UI4iezrvm9nw == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduledrvdehgdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpeffhffvuffkfhggtggujgesthdtredttddtvdenucfhrhhomhepifhrvghgucfm jfcuoehgrhgvgheskhhrohgrhhdrtghomheqnecuggftrfgrthhtvghrnhepveeuheejgf ffgfeivddukedvkedtleelleeghfeljeeiueeggeevueduudekvdetnecukfhppeekfedr keeirdejgedrieegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilh hfrhhomhepghhrvghgsehkrhhorghhrdgtohhm X-ME-Proxy: Received: from localhost (83-86-74-64.cable.dynamic.v4.ziggo.nl [83.86.74.64]) by mail.messagingengine.com (Postfix) with ESMTPA id 8E0C31080057; Tue, 26 Jan 2021 08:51:30 -0500 (EST) Date: Tue, 26 Jan 2021 14:51:29 +0100 From: Greg KH To: Justin Forbes Cc: Josh Poimboeuf , Masahiro Yamada , Kees Cook , Linux Kernel Mailing List , Michal Marek , linux-hardening@vger.kernel.org, Linux Kbuild mailing list , Peter Zijlstra , Ondrej Mosnacek Subject: Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules Message-ID: References: <20210125212755.jfwlqogpcarmxdgt@treble> <20210125220757.vxdsf6sttpy46cq7@treble> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 26, 2021 at 06:44:44AM -0600, Justin Forbes wrote: > On Tue, Jan 26, 2021 at 2:21 AM Greg KH wrote: > > > > On Mon, Jan 25, 2021 at 04:07:57PM -0600, Josh Poimboeuf wrote: > > > On Tue, Jan 26, 2021 at 06:44:35AM +0900, Masahiro Yamada wrote: > > > > > > If people use a different compiler, they must be > > > > > > prepared for any possible problem. > > > > > > > > > > > > Using different compiler flags for in-tree and out-of-tree > > > > > > is even more dangerous. > > > > > > > > > > > > For example, CONFIG_GCC_PLUGIN_RANDSTRUCT is enabled > > > > > > for in-tree build, and then disabled for out-of-tree modules, > > > > > > the struct layout will mismatch, won't it? > > > > > > > > > > If you read the patch you'll notice that it handles that case, when it's > > > > > caused by GCC mismatch. > > > > > > > > > > However, as alluded to in the [1] footnote, it doesn't handle the case > > > > > where the OOT build system doesn't have gcc-plugin-devel installed. > > > > > Then CONFIG_GCC_PLUGIN_RANDSTRUCT gets silently disabled and the build > > > > > succeeds! That happens even without a GCC mismatch. > > > > > > > > > > > > Ah, sorry. > > > > > > > > I responded too early before reading the patch fully. > > > > > > > > But, I do not like to make RANDSTRUCT a special case. > > > > > > > > I'd rather want to stop building for any plugin. > > > > > > Other than RANDSTRUCT there doesn't seem to be any problem with > > > disabling them (and printing a warning) in the OOT build. Why not give > > > users that option? It's harmless, and will make distro's (and their > > > users') lives easier. > > > > > > Either GCC mismatch is ok, or it's not. Let's not half-enforce it. > > > > As I said earlier, it's not ok, we can not support it at all. > > > > Support and enforce are 2 completely different things. To shed a bit > more light on this, the real issue that prompted this was breaking CI > systems. As we enabled gcc plugins in Fedora, and the toolchain folks > went through 3 different snapshots of gcc 11 in a week. Any CI process > that built an out of tree module failed. I don't think this is nearly > as much of a concern for stable distros, as it is for CI in > development cycles. It's better to have an obvious break like this than to silently accept things and then have a much harder issue to debug at runtime, right? Don't allow things that we know we will not support, this sounds like an issue with your CI systems, not with the kernel build system, why not just fix that? :) thnaks, greg k-h