From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 6347A2CA4 for ; Fri, 8 Apr 2022 20:09:01 +0000 (UTC) Received: by mail-lj1-f178.google.com with SMTP id by7so12928982ljb.0 for ; Fri, 08 Apr 2022 13:09:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=/UM0a9Ip3D6RdnaIa3xh2eGdIk2IGdD4yqLErApCSxM=; b=CI/CYvGTarILQMchP5s65Nb1hnUDQsMrJh6w+c+dkUl2F0BUOL2kuCeFcTeCQbJYjI yGMOzFWpjq2/2dCurKDzl4jWsQWHpb2kim/he4cP+VpQJ0ZUStRZGBNXrdgeYq6+Tfcu HjaA3//xCR8FdmJPvzvsB8Ewe4ysqg6aLbknQWkkmP6TJjHR3vNr+HzAxJJOsvVYFhqe DmwZKjCy0D1h/BU8V9rycAcdezkBXyYJ37skY+HbruIkrt7zeynpUygEOMwl2hyy8C0g wByJvNnOaCJ+Uita54VhBO6KQ5POwGmjgBjBNZO9b95Q/C+Pm4W3XcqpBs23OKtumbWW UFXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=/UM0a9Ip3D6RdnaIa3xh2eGdIk2IGdD4yqLErApCSxM=; b=jfVeTG2JyaXfg6F6NytDE1VQ5d6m6BFLtrp5BmDCWtE0XkCDqF2GYLiTarRee9XtUJ LgLEfmlWPv73LfDutEeM4Yqc6LipELLjFZYseQAiy5E0SLP41cFtvX24sBHUl7KqMxXl YzeBLjn1t6KxyLIm90IVChfjzLXhx+NfSXhQHp3uLeje48HwRs4wBEzwJYaaFqx91z3b Fm00Mm03rsvr9LP2Ubr+H4CWNIPBoEBmIQkYzzweFbzJ0tc4i1c779OnBLd5EzeiB4pt weOS73db0HSzfedjVNU06tlsfZOn5FhLFexx/MBxxS4aRHo44/g6mqF213AwqQwh+ZP5 xpyQ== X-Gm-Message-State: AOAM531DpmVCz7q4PpG3B1Gc96T6TpxIJvPbn/tOGS6vsDUb2OhqoQ1B bekoL/HwHS8okTg4qtyc94a4eqXAG1T+lA/8zS+Niw== X-Google-Smtp-Source: ABdhPJxn/j+3hhBgpW18trIa+1ld5yDFBq4oZ1pt7YDIhvl7m7bWgtTber0s7bQ9iWmBxG7ZeR/kNzR+h6Y+rAp8XlM= X-Received: by 2002:a05:651c:555:b0:24b:15b7:74ad with SMTP id q21-20020a05651c055500b0024b15b774admr12406043ljp.239.1649448539126; Fri, 08 Apr 2022 13:08:59 -0700 (PDT) Precedence: bulk X-Mailing-List: llvm@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <7fad83ecde03540e65677959034315f8fbb3755e.1649434832.git.jpoimboe@redhat.com> In-Reply-To: From: Nick Desaulniers Date: Fri, 8 Apr 2022 13:08:47 -0700 Message-ID: Subject: Re: [PATCH] kbuild: Remove CONFIG_DEBUG_SECTION_MISMATCH To: Peter Zijlstra , Masahiro Yamada , Josh Poimboeuf Cc: Michal Marek , Linux Kernel Mailing List , Linux Kbuild mailing list , Sam Ravnborg , X86 ML , Arnd Bergmann , Changbin Du , linux-toolchains@vger.kernel.org, clang-built-linux Content-Type: text/plain; charset="UTF-8" Lore thread start for newly cc'ed ML readers: https://lore.kernel.org/lkml/7fad83ecde03540e65677959034315f8fbb3755e.1649434832.git.jpoimboe@redhat.com/ On Fri, Apr 8, 2022 at 12:14 PM Peter Zijlstra wrote: > > On Sat, Apr 09, 2022 at 03:29:21AM +0900, Masahiro Yamada wrote: > > Is [2] caused by dead code that was not optimized out > > due to the unusual inlining decisions by the compiler ? > > The complaint is due to SMAP validation; objtool will scream if there's > a CALL in between STAC/CLAC. The thinking is that since they open a > security window, we want tight code between them. We also very much > don't want tracing and other funnies to happen there. As such, any CALL > is dis-allowed. Just indirect calls, which might be manipulated, or static calls, too? > > This weird option is having us upgrade quite a few 'inline' to > '__always_inline'. As is, the assumption that __init functions only call other __init functions or __always_inline is a brittle house of cards that leads to a "what color is your function" [0] scenario, and leads to code that happens to not emit warnings for compiler X (or compiler X version Y). There's also curious exceptions in modpost that look like memory leaks to me. We already have such toolchain portability issues for different toolchains and different configs; warnings from section mismatches, and objtool STAC/CLAC checks. I feel that Josh's patch would sweep more of those under the rug, so I'm not in favor of it, but could be convinced otherwise. TBH, I kind of think that we could use a C extension to permit __attribute__((always_inline)) to additionally be a statement attribute, rather than just a function attribute because of cases like this; we need the flexibility to make one call site __always_inline without necessarily forcing ALL callsites to be __always_inline'd. void y (void); void x (void) { __attribute__((always_inline)) y(); }; (This is already expressable in LLVM IR; not (yet) in C. I'm not sure yet _why_ this was added to LLVM; whether a different language front end can express this, if C can and I'm mistaken, or whether it's only used for optimizations). I think that would give developers maximal flexibility to defer as much to the compiler's inlining decisions when they don't care, and express precisely what they need when they do [care]. [0] https://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ -- Thanks, ~Nick Desaulniers