From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 04DC5C63697 for ; Sat, 14 Nov 2020 10:20:42 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 919332225E for ; Sat, 14 Nov 2020 10:20:41 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=kernel.org header.i=@kernel.org header.b="sl0SkJKK" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726701AbgKNKUc (ORCPT ); Sat, 14 Nov 2020 05:20:32 -0500 Received: from mail.kernel.org ([198.145.29.99]:39502 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726513AbgKNKUb (ORCPT ); Sat, 14 Nov 2020 05:20:31 -0500 Received: from mail-oi1-f176.google.com (mail-oi1-f176.google.com [209.85.167.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 51D6F22265 for ; Sat, 14 Nov 2020 10:20:30 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1605349230; bh=OHDt0wHQUINwdyuR2kBWlrKwJNuOkKSa4LmDc8c34dk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=sl0SkJKKRO9D8ya6LmeAbsNsNVyuUBYPDPJoB+DXWoBXiR36NhnLOEcKRQWfU9gKM zoXzkjZEosQ3voOSN954Vc40SAvK1yGQvxJuv3HXNJkzwJJoeRs7uKkwhTFLqNDgFG s/l8wH/KId6f0dsY+RJymCf4X9Vj3R7CTP8nRt48= Received: by mail-oi1-f176.google.com with SMTP id c80so13383128oib.2 for ; Sat, 14 Nov 2020 02:20:30 -0800 (PST) X-Gm-Message-State: AOAM533PUVr7Gf03va/kACSrjXEVY6WcbHZGCz+EEWE1P64O5nXZHt6P 0e1+fY21EACud2vEkd9QWg2gULQVsT3ff0LeQMo= X-Google-Smtp-Source: ABdhPJyScCbX8MgDIievQ8LgNwcLs5ngYnMHbfdyVKnuCIE57zGo7WTHBNk7bnY+dYPVgiH6JfXg1Hz3esXHrQ+5weQ= X-Received: by 2002:aca:c60c:: with SMTP id w12mr4568661oif.174.1605349229544; Sat, 14 Nov 2020 02:20:29 -0800 (PST) MIME-Version: 1.0 References: <20201109144425.270789-22-alexandre.chartre@oracle.com> <202011131552.4kvOb9Id-lkp@intel.com> <20201113234701.GV2672@gate.crashing.org> <20201114002624.GX2672@gate.crashing.org> In-Reply-To: From: Ard Biesheuvel Date: Sat, 14 Nov 2020 11:20:17 +0100 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [RFC][PATCH 21/24] x86/entry: Disable stack-protector for IST entry C handlers To: Miguel Ojeda Cc: Segher Boessenkool , Nick Desaulniers , Alexandre Chartre , kbuild-all@lists.01.org, clang-built-linux , linux-toolchains@vger.kernel.org, kernel test robot , Arvind Sankar Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-toolchains@vger.kernel.org On Sat, 14 Nov 2020 at 02:59, Miguel Ojeda wrote: > > On Sat, Nov 14, 2020 at 1:27 AM Segher Boessenkool > wrote: > > > > But you cannot limit yourself to the greatest common denominator: the > > kernel wants to use many features only available on newer compiler > > versions, too; this is no different. > > What we do is conditionally enable both new and differentiating > features. We don't break GCC or LLVM just because the other introduces > a new shiny feature, nor we break builds with old compilers (except > when raising the minimum supported version). > > That is why we need a level of indirection in things like attributes > nowadays, and why patches like the above are not ideal anymore > (regardless of which attribute we are talking about). > In spite of the apparent difference of opinion here, there are two irrefutable facts about __attribute__((optimize)) on GCC that can only lead to the conclusion that we must never use it in Linux: - the GCC developers refuse to rigorously define its behavior, so we don't know what it actually does; - it has been observed to nullify unrelated command line arguments in unexpected and undocumented ways. So it does not matter whether you call that quirky or something else, there is no way we can make meaningful use of it, and therefore, abstracting or parameterizing any of its uses should be avoided as well.