Received: by 2002:a05:6a10:8c0a:0:0:0:0 with SMTP id go10csp4112817pxb; Tue, 26 Jan 2021 12:45:13 -0800 (PST) X-Google-Smtp-Source: ABdhPJwsmOvba4hA9aF/HW+s4DHON8Fn4E+AYsh+PKed0aic5qNcpZUQePq07nBdpcgqa8rUsdg3 X-Received: by 2002:a17:906:49c2:: with SMTP id w2mr4433982ejv.12.1611693913617; Tue, 26 Jan 2021 12:45:13 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1611693913; cv=none; d=google.com; s=arc-20160816; b=qdmU7vTlkkU1a94rR5lHN+JOuse3QeH1E7TSiXVEVcWphdREQgbDLLP9DHRPNCdkTm bZiDF6Y6aqdUIjrESP7Qhb4acZfb0I8UHzDgXI/4c+SftQDv/XVZofEtGLLvK0pwQks9 hbIeUKP9kLE7s9dz7+QqT7YtkpAhGEYF6NmjAel+zK6L/jscR4uP+NxDwMdtVNwaDD7C xSYLy/Ld8ZGcoqZZeCPYRat6MuMZplRxltFieXZ1V5D4LdjBsm7KLkYjjYOShPH/kun2 skmNVpvrXGc3TFtpfRtG4bRF657M6HcfCKU0TeKmwFr0bfMElKs5kJxPwCKl94KY2g4Q DhYg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=TLtZhIl7orO56MT5FcvC4puD6EhsLgMtbBTl1Sh9rT4=; b=MUnuGqFlXmFXTC27pAPUMlQWQ4FSuvjPWeSpn/Q7BLsD5F/w0kjlf1jH+yzvwuOQsB mq8bCfxNtliOQiEPRUWgd6bv+nfadI+XS9YSvFbL7wtilwhEr/qWfkqfy/nOBg8qKWcM HqWrvrRn+N4TrbSlsOhfcL/1OrcsTc8C8KIqK0UYkfr4fk+Gy9JvMd+JoqDomYmgOx5l vNP3p0rfl5gH//Z4HjndcQ1we6O4n/EYETG7S8m51fLjsjj6bYOXwXGnCc5Ukjr/rgGl RjAwk19udV9kpAENlByXwuAjBbrks2vmXkKeQGlES3CPxkIa9APPhnayXy1l043EPQOb JCLQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=ROeHlGry; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r23si7452786ejr.57.2021.01.26.12.44.48; Tue, 26 Jan 2021 12:45:13 -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=@redhat.com header.s=mimecast20190719 header.b=ROeHlGry; 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; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2394329AbhAZSP2 (ORCPT + 99 others); Tue, 26 Jan 2021 13:15:28 -0500 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:39856 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2393391AbhAZRsz (ORCPT ); Tue, 26 Jan 2021 12:48:55 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1611683248; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=TLtZhIl7orO56MT5FcvC4puD6EhsLgMtbBTl1Sh9rT4=; b=ROeHlGry6v6pXrjKDCe/eDFEOK6G5AUiEjms4jHD3lLAC+qZnefwLsum9OWbpx14l/KPv3 R4+b26Vku1fXEsguPCuwre1ZnAkvzpsNXu0GcK3kLW9aMzfvUWyzl87PE+EF1aL0r1xqN3 t3sf0HthondGOYrqQLpMJGuN0ztQcvg= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-510-sZBPqrYnOqqIZjly65phPg-1; Tue, 26 Jan 2021 12:47:26 -0500 X-MC-Unique: sZBPqrYnOqqIZjly65phPg-1 Received: by mail-wm1-f70.google.com with SMTP id q24so1690513wmc.1 for ; Tue, 26 Jan 2021 09:47:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=TLtZhIl7orO56MT5FcvC4puD6EhsLgMtbBTl1Sh9rT4=; b=aDBbSsuHMVjfI2U0/1zWMZ9rHCjM1ZasL911WCZTaK0BKQuhU2eBp2BYb4kSqQyVG8 crUojTTHEsoJeCTv7UJFmwNQLLsEcCj+7imfOw13fiAtRNeVlPX+DWfWX6e2K7AnWek0 Q3j8WIFaJibnDDfr1hSkqH9hwhOr+M3Au3JoVJs5TJUj8z0Hy8psp0MrtZgdC+nXhrlS bMVykGcWReMDYZzv2lKPERozVEpQKMyoD7rTUKJr65cmCahtD0mX0IqINqVdDHJ6L4Hu THRAiMMIzZ5cE9xSgDYq/pHSOZO8nuu05nnKBdm0HnbNVasrDM6TRY/qMTNzy87qflGx 0l7A== X-Gm-Message-State: AOAM5321Bz4wMKq9L4ItVlChpI8SxsHNpYVVI77U65lR8WqMvQn4QVAM AFLyC2SO8ziIjUwYYAgnDEzp2SpcdxZqQJ4o0xWJFITE61Pxztn6EVqGi578fvxGbAn8RZ/CXlA jSEkBX3VzodbeashedIGZQSB+UKQFfIAe9l/VX9sM X-Received: by 2002:a5d:58fa:: with SMTP id f26mr7484826wrd.33.1611683245138; Tue, 26 Jan 2021 09:47:25 -0800 (PST) X-Received: by 2002:a5d:58fa:: with SMTP id f26mr7484806wrd.33.1611683244863; Tue, 26 Jan 2021 09:47:24 -0800 (PST) MIME-Version: 1.0 References: <20210125220757.vxdsf6sttpy46cq7@treble> <20210126145155.kcfbnzfqg5qugvcl@treble> <20210126154651.itfrnhwfistia3ss@treble> <20210126161934.z6sng4irl5teonvj@treble> In-Reply-To: From: Justin Forbes Date: Tue, 26 Jan 2021 11:47:13 -0600 Message-ID: Subject: Re: [PATCH RFC] gcc-plugins: Handle GCC version mismatch for OOT modules To: Greg KH Cc: Josh Poimboeuf , Peter Zijlstra , Masahiro Yamada , Kees Cook , Linux Kernel Mailing List , Michal Marek , linux-hardening@vger.kernel.org, Linux Kbuild mailing list , Ondrej Mosnacek Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 26, 2021 at 11:07 AM Greg KH wrote: > > On Tue, Jan 26, 2021 at 10:19:34AM -0600, Josh Poimboeuf wrote: > > On Tue, Jan 26, 2021 at 10:15:52AM -0600, Justin Forbes wrote: > > > On Tue, Jan 26, 2021 at 10:05 AM Peter Zijlstra wrote: > > > > > > > > On Tue, Jan 26, 2021 at 09:46:51AM -0600, Josh Poimboeuf wrote: > > > > > On Tue, Jan 26, 2021 at 04:15:37PM +0100, Peter Zijlstra wrote: > > > > > > On Tue, Jan 26, 2021 at 08:51:55AM -0600, Josh Poimboeuf wrote: > > > > > > > User space mixes compiler versions all the time. The C ABI is stable. > > > > > > > > > > > > > > What specifically is the harder issue you're referring to? > > > > > > > > > > > > I don't think the C ABI captures nearly enough. Imagine trying to mix a > > > > > > compiler with and without asm-goto support (ok, we fail to build without > > > > > > by now, but just imagine). > > > > > > > > > > > > No C ABI violated, but having that GCC extention vs not having it > > > > > > radically changes the kernel ABI. > > > > > > > > > > > > I think I'm with Greg here, just don't do it. > > > > > > > > > > Ok, thank you for an actual example. asm goto is a good one. > > > > > > > > > > But it's not a cut-and-dry issue. Otherwise how could modversions > > > > > possibly work? > > > > > > > > > > So yes, we should enforce GCC versions, but I still haven't seen a > > > > > reason it should be more than just "same compiler and *major* version". > > > > > > > > Why bother? rebuilding the kernel and all modules is a matter of 10 > > > > minutes at most on a decently beefy build box. > > > > > > > > What actual problem are we trying to solve here? > > > > > > This is true for those of us used to working with source and building > > > by hand. For users who want everything packaged, rebuilding a kernel > > > package for install is considerably longer, and for distros providing > > > builds for multiple arches, we are looking at a couple of hours at > > > best. From a Fedora standpoint, I am perfectly fine with it failing > > > if someone tries to build a module on gcc10 when the kernel was built > > > with gcc11. It's tedious when the kernel was built with gcc11 > > > yesterday, and a new gcc11 build today means that kernel needs to be > > > rebuilt. > > > > Right. It's a problem for distro users. The compiler and kernel are in > > separate packages, with separate release cadences. The latest compiler > > version may not exactly match what was used to build the latest kernel. > > Given that distros _should_ be updating their kernel faster than the > compiler updates, what's the real issue here? You build a kernel, and > all external modules, at the same time. If you want to build them at > different times, you make your build system ensure they were the same > compiler so that you are "bug compatible". > > And yes, it might be a pain if gcc11 gets updated every other day, but > as someone living with a "rolling-distro" you get used to it, otherwise > you just "pin" the build tools and keep that from happening. > > This isn't a new thing, we've been doing this for decades, why is this > surprising? We definitely build considerably more kernels than toolchains. From a rawhide standpoint though, a number of testers are willing to test RC releases, but are not willing to run debug kernels, so they installed rc4 yesterday, but will not install today's snapshot. I will build 3-5 new kernels before they update to rc5. We have been doing things this way for over a decade. It has never been a problem until we turned on CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL. Suddenly I am getting complaints.