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=-3.9 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,INCLUDES_PATCH, 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 9BF40C47247 for ; Thu, 7 May 2020 14:07:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 73CAB2083B for ; Thu, 7 May 2020 14:07:48 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="cMmKQFVQ" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727989AbgEGOHr (ORCPT ); Thu, 7 May 2020 10:07:47 -0400 Received: from us-smtp-2.mimecast.com ([207.211.31.81]:25736 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727903AbgEGOHn (ORCPT ); Thu, 7 May 2020 10:07:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588860462; 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=1AoI+9FyMu82WK4bZhrAK5V8JQ6RWrNZsFQbYJw2lb8=; b=cMmKQFVQKKGKi3A8eBf2pDOFVWfZ3LjO2ZMbKfUXlf9oawbecNEEhbqTgFaDDUfOuDs0R9 xVhVVpQr6wHX86PxsWk98agb14s+azuxCpcxfnlRKAIXwdVfayaE36zuSseN22EpvYty4y C4kNaIgIivoqetuU4Pugr6eQXNMqyfs= Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-61-vKGhe_kQMd-SMc6q1mPVXw-1; Thu, 07 May 2020 10:07:39 -0400 X-MC-Unique: vKGhe_kQMd-SMc6q1mPVXw-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 422AA460; Thu, 7 May 2020 14:07:37 +0000 (UTC) Received: from treble (ovpn-115-96.rdu2.redhat.com [10.10.115.96]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 059E670545; Thu, 7 May 2020 14:07:35 +0000 (UTC) Date: Thu, 7 May 2020 09:07:33 -0500 From: Josh Poimboeuf To: Alexei Starovoitov Cc: Alexei Starovoitov , Daniel Borkmann , Network Development , bpf , LKML , X86 ML , Peter Zijlstra , Randy Dunlap , Arnd Bergmann Subject: Re: [PATCH] bpf: Tweak BPF jump table optimizations for objtool compatibility Message-ID: <20200507140733.v4xlzjogtnpgu5lc@treble> References: <20200502192105.xp2osi5z354rh4sm@treble> <20200505174300.gech3wr5v6kkho35@ast-mbp.dhcp.thefacebook.com> <20200505181108.hwcqanvw3qf5qyxk@treble> <20200505195320.lyphpnprn3sjijf6@ast-mbp.dhcp.thefacebook.com> <20200505202823.zkmq6t55fxspqazk@treble> <20200505235939.utnmzqsn22cec643@ast-mbp.dhcp.thefacebook.com> <20200506155343.7x3slq3uasponb6w@treble> <20200506211945.4qhrxqplzmt4ul66@treble> <20200507000357.grprluieqa324v5c@ast-mbp.dhcp.thefacebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200507000357.grprluieqa324v5c@ast-mbp.dhcp.thefacebook.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 06, 2020 at 05:03:57PM -0700, Alexei Starovoitov wrote: > > > > > diff --git a/include/linux/compiler-gcc.h b/include/linux/compiler-gcc.h > > > > > index d7ee4c6bad48..05104c3cc033 100644 > > > > > --- a/include/linux/compiler-gcc.h > > > > > +++ b/include/linux/compiler-gcc.h > > > > > @@ -171,4 +171,4 @@ > > > > > #define __diag_GCC_8(s) > > > > > #endif > > > > > > > > > > -#define __no_fgcse __attribute__((optimize("-fno-gcse"))) > > > > > +#define __no_fgcse __attribute__((optimize("-fno-gcse,-fno-omit-frame-pointer"))) > > > > > -- > > > > > 2.23.0 > > > > > > > > > > I've tested it with gcc 8,9,10 and clang 11 with FP=y and with ORC=y. > > > > > All works. > > > > > I think it's safer to go with frame pointers even for ORC=y considering > > > > > all the pain this issue had caused. Even if objtool gets confused again > > > > > in the future __bpf_prog_run() will have frame pointers and kernel stack > > > > > unwinding can fall back from ORC to FP for that frame. > > > > > wdyt? > > > > > > > > It seems dangerous to me. The GCC manual recommends against it. > > > > > > The manual can says that it's broken. That won't stop the world from using it. > > > Just google projects that are using it. For example: qt, lz4, unreal engine, etc > > > Telling compiler to disable gcse via flag is a guaranteed way to avoid > > > that optimization that breaks objtool whereas messing with C code is nothing > > > but guess work. gcc can still do gcse. > > > > But the manual's right, it is broken. How do you know other important > > flags won't also be stripped? > > What flags are you worried about? > I've checked that important things like -mno-red-zone, -fsanitize are preserved. It's not any specific flags I'm worried about, it's all of them. There are a lot of possibilities, with all the different configs, and arches. Flags are usually added for a good reason, so one randomly missing flag could have unforeseen results. And I don't have any visibility into how GCC decides which flags to drop, and when. But the docs aren't comforting. Even if things seem to work now, that could (silently) change at any point in time. This time objtool warned about the missing frame pointer, but that's not necessarily going to happen for other flags. If we go this route, I would much rather do -fno-gcse on a file-wide basis. -- Josh