Received: by 2002:a05:6a10:9e8c:0:0:0:0 with SMTP id y12csp691898pxx; Wed, 28 Oct 2020 14:39:36 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzJnmhAAJ6sG97KyOieKth1MvXfMhGxba2T6SaS2UAW9h5vbzIYywI+qhlXoazEb6j7U5Ci X-Received: by 2002:a50:d517:: with SMTP id u23mr967363edi.338.1603921176591; Wed, 28 Oct 2020 14:39:36 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603921176; cv=none; d=google.com; s=arc-20160816; b=X75Jdppt7J2l9Spxm/GipiKzr232PuQOb8y0dYidkwj8CcXax8w5w/gOdk54LACkEY q5T2SCT+/1BWClw42lEzKqI+xgALwILMKG/8jYvZ7Oi1zD9ij5MlLcCT5rfNh+UGCGwA /n3m0n6H7lACSVaIdMhgKjkBXG/B6AuBYg1jV+50KT0rJcJFVzDPxQR1wgtSrq9e2spe pitYoIAu/TCDzccjNzbtO3X26NVA16e+JOZX6nXKyQqXkrXe/lP06QZbLSpGILWDLxJr 5OvYa+Y46ej6aTuK6KqRxqzjtKyjngfYcTz8br8joVG4m8npd2XaTFxRoSzYjEP1ruL7 NTBg== 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=KiW0Es6GhZG0mD0vaT0CFwu3U3DQdlwHqN8ZFRjOohU=; b=D59XO65B9UU1gkkAtZe/vCzKVL4U3KUkV/g8o3qIycNyTHzrAsdlIiQng2cjlYPBkn ckes2bB3boimGKO/kcdU+kP4lEbU/Xxb3QB5ROSoIkiB4kvWujbmL4xi0eO6ZiWSVWHj otvAFvHX9UCe5uTZlvV2DvFd5UdNNB1yF3+pRv+7CwVeTrHrqiTbahh/Ha6tjsh/ztIt EXYTO7Ee4MAZhdpDrP/Utj01Z67+pLz7RO/DnW3jX4NIiwblBiTly1jwcZh9ryVesJsB 1JD17m+V8aXLaommxxVXwApCWNmSYnLEWFNSumej2pUKzCKyJ0RPb/oY8jzgt9OnxDrp se3g== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=OnoFJ4LX; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id se13si392566ejb.702.2020.10.28.14.39.15; Wed, 28 Oct 2020 14:39:36 -0700 (PDT) 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=@google.com header.s=20161025 header.b=OnoFJ4LX; 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=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S373738AbgJ0VUN (ORCPT + 99 others); Tue, 27 Oct 2020 17:20:13 -0400 Received: from mail-pg1-f193.google.com ([209.85.215.193]:47089 "EHLO mail-pg1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2504989AbgJ0VUM (ORCPT ); Tue, 27 Oct 2020 17:20:12 -0400 Received: by mail-pg1-f193.google.com with SMTP id n16so1501081pgv.13 for ; Tue, 27 Oct 2020 14:20:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KiW0Es6GhZG0mD0vaT0CFwu3U3DQdlwHqN8ZFRjOohU=; b=OnoFJ4LXia3k2waYWJDZV1WhNFTdh1HpJbZ+YQBNuJXR6UWaBQtQJs016gXMZrLUL4 jeXFlYBEiJQsj0CoDdF3gLflYJTepQKJW7oMQsE3c7KjZbkwXmtVVwoLv5y6F4Lifw+v u+qHc3gWVNlre0nvgEj5IZ85/tRiTy8piIrIPVQr8ucoi0C/7qAZ2F3+wF5aZ0kV0HpS XwZL7/JRi3HUgjySOjVrUMob6wDz11/dTXtx4muODCn2lpg4LqVVOAYpPOP8dxXYMBDW mnBPDFZAyqxNDTlSlt8eVzLRkuz5+Vlzdw2FHWiOdLJawSjLhXYtAMN9j5LLfQ7/rDyy F2ew== 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=KiW0Es6GhZG0mD0vaT0CFwu3U3DQdlwHqN8ZFRjOohU=; b=R7G/oozujnqgoO/3NUlCQgQldP4vpmeKw2lIjXNAjsEa0I86SR2ArUAuXcrC3SQFXc SoXvmEprzyiOMZpm+yioWT5WieAsaXf2BfsEi+c+PVqD9uM7jL0mUSqiM/6GIhP/Lbqn mugV63YfhKWzeTpnDYvy2+LQ6LsWV07uSdxJM6Xi37UmXXylpUiaBpJzqwomhshIr8Ut QGlN9/ClbV26fB2NgEFpq8KdBuNy7zZSYV3sax/cZR2SuY6tuESSAXYArKtRTvHtP98/ oYVU2wCfYcWZ5WfKgZF/h4mWqgwy/WShE+AsAEy+NrjCV/qS2vfnzRv4e5Y+k87Q9vbP EdxA== X-Gm-Message-State: AOAM5309/t8UaoiRYA7CMCxV709z+q1nd9VFvNVJqpz6Un5IKeO03iLQ LqbDyPdPYoL0/ef+GcFRJVkOfIPr9Q3V1pAmiWajnA== X-Received: by 2002:a63:5152:: with SMTP id r18mr3339543pgl.381.1603833611528; Tue, 27 Oct 2020 14:20:11 -0700 (PDT) MIME-Version: 1.0 References: <20201027205723.12514-1-ardb@kernel.org> In-Reply-To: <20201027205723.12514-1-ardb@kernel.org> From: Nick Desaulniers Date: Tue, 27 Oct 2020 14:20:00 -0700 Message-ID: Subject: Re: [PATCH] bpf: don't rely on GCC __attribute__((optimize)) to disable GCSE To: Ard Biesheuvel Cc: LKML , Network Development , bpf , Arnd Bergmann , Arvind Sankar , Randy Dunlap , Josh Poimboeuf , Thomas Gleixner , Alexei Starovoitov , Daniel Borkmann , Peter Zijlstra , Geert Uytterhoeven , Kees Cook Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 27, 2020 at 1:57 PM Ard Biesheuvel wrote: > > Commit 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for > ___bpf_prog_run()") introduced a __no_fgcse macro that expands to a > function scope __attribute__((optimize("-fno-gcse"))), to disable a > GCC specific optimization that was causing trouble on x86 builds, and > was not expected to have any positive effect in the first place. > > However, as the GCC manual documents, __attribute__((optimize)) > is not for production use, and results in all other optimization > options to be forgotten for the function in question. This can > cause all kinds of trouble, but in one particular reported case, > it causes -fno-asynchronous-unwind-tables to be disregarded, > resulting in .eh_frame info to be emitted for the function > inadvertently. > > This reverts commit 3193c0836f203, and instead, it disables the -fgcse > optimization for the entire source file, but only when building for > X86. > > Cc: Nick Desaulniers > Cc: Arvind Sankar > Cc: Randy Dunlap > Cc: Josh Poimboeuf > Cc: Thomas Gleixner > Cc: Alexei Starovoitov > Cc: Daniel Borkmann > Cc: Peter Zijlstra (Intel) > Cc: Geert Uytterhoeven > Cc: Kees Cook > Fixes: 3193c0836f203 ("bpf: Disable GCC -fgcse optimization for ___bpf_prog_run()") > Signed-off-by: Ard Biesheuvel > --- > include/linux/compiler-gcc.h | 2 -- > include/linux/compiler_types.h | 4 ---- > kernel/bpf/Makefile | 4 +++- > kernel/bpf/core.c | 2 +- > 4 files changed, 4 insertions(+), 8 deletions(-) > > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h > index d1e3c6896b71..5deb37024574 100644 > --- a/include/linux/compiler-gcc.h > +++ b/include/linux/compiler-gcc.h > @@ -175,5 +175,3 @@ > #else > #define __diag_GCC_8(s) > #endif > - > -#define __no_fgcse __attribute__((optimize("-fno-gcse"))) > diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h > index 6e390d58a9f8..ac3fa37a84f9 100644 > --- a/include/linux/compiler_types.h > +++ b/include/linux/compiler_types.h > @@ -247,10 +247,6 @@ struct ftrace_likely_data { > #define asm_inline asm > #endif > > -#ifndef __no_fgcse > -# define __no_fgcse > -#endif > - > /* Are two types/vars the same type (ignoring qualifiers)? */ > #define __same_type(a, b) __builtin_types_compatible_p(typeof(a), typeof(b)) > > diff --git a/kernel/bpf/Makefile b/kernel/bpf/Makefile > index bdc8cd1b6767..02b58f44c479 100644 > --- a/kernel/bpf/Makefile > +++ b/kernel/bpf/Makefile > @@ -1,6 +1,8 @@ > # SPDX-License-Identifier: GPL-2.0 > obj-y := core.o > -CFLAGS_core.o += $(call cc-disable-warning, override-init) > +# ___bpf_prog_run() needs GCSE disabled on x86; see 3193c0836f203 for details > +cflags-core-$(CONFIG_X86) := -fno-gcse -fno-gcse is not recognized by clang and will produce -Wignored-optimization-argument. It should at least be wrapped in cc-option, though since it's unlikely to ever not be compiler specific, I think it might be ok to guard with `ifdef CONFIG_CC_IS_GCC`. Also, might we want to only do this for `ifndef CONFIG_RETPOLINE`, based on 3193c0836f203? Finally, this is going to disable GCSE for the whole translation unit, which may be overkill. Previously it was isolated to one function definition. You could lower the definition of the preprocessor define into kernel/bpf/core.c to keep its use isolated as far as possible. I'm fine with either approach, but we should avoid new warnings for clang. Thanks for the patch! > +CFLAGS_core.o += $(call cc-disable-warning, override-init) $(cflags-core-y) > > obj-$(CONFIG_BPF_SYSCALL) += syscall.o verifier.o inode.o helpers.o tnum.o bpf_iter.o map_iter.o task_iter.o prog_iter.o > obj-$(CONFIG_BPF_SYSCALL) += hashtab.o arraymap.o percpu_freelist.o bpf_lru_list.o lpm_trie.o map_in_map.o > diff --git a/kernel/bpf/core.c b/kernel/bpf/core.c > index 9268d77898b7..55454d2278b1 100644 > --- a/kernel/bpf/core.c > +++ b/kernel/bpf/core.c > @@ -1369,7 +1369,7 @@ u64 __weak bpf_probe_read_kernel(void *dst, u32 size, const void *unsafe_ptr) > * > * Decode and execute eBPF instructions. > */ > -static u64 __no_fgcse ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack) > +static u64 ___bpf_prog_run(u64 *regs, const struct bpf_insn *insn, u64 *stack) > { > #define BPF_INSN_2_LBL(x, y) [BPF_##x | BPF_##y] = &&x##_##y > #define BPF_INSN_3_LBL(x, y, z) [BPF_##x | BPF_##y | BPF_##z] = &&x##_##y##_##z > -- > 2.17.1 > -- Thanks, ~Nick Desaulniers