From: Arnd Bergmann <arnd@arndb.de>
To: Peter Zijlstra <peterz@infradead.org>
Cc: Masahiro Yamada <masahiroy@kernel.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Michal Marek <michal.lkml@markovi.net>,
Nick Desaulniers <ndesaulniers@google.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linux Kbuild mailing list <linux-kbuild@vger.kernel.org>,
Sam Ravnborg <sam@ravnborg.org>, X86 ML <x86@kernel.org>,
Arnd Bergmann <arnd@arndb.de>,
Changbin Du <changbin.du@gmail.com>
Subject: Re: [PATCH] kbuild: Remove CONFIG_DEBUG_SECTION_MISMATCH
Date: Sat, 9 Apr 2022 12:33:18 +0200 [thread overview]
Message-ID: <CAK8P3a3xoUJ=aDROkWQ1Awpu0kiciohL7hJNsQ0Zn0K05bWObQ@mail.gmail.com> (raw)
In-Reply-To: <YlCJm8iQBPSOWIT5@hirez.programming.kicks-ass.net>
On Fri, Apr 8, 2022 at 9:14 PM Peter Zijlstra <peterz@infradead.org> 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.
>
> This weird option is having us upgrade quite a few 'inline' to
> '__always_inline'.
There is also __attribute__((flatten)), which you can add to the caller
to tell gcc to inline everything it can into this function, without
having to inline it everywhere else.
Would that work here? It sounds like this is what STAC/CLAC actually
requires.
Arnd
next prev parent reply other threads:[~2022-04-09 10:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-08 16:21 [PATCH] kbuild: Remove CONFIG_DEBUG_SECTION_MISMATCH Josh Poimboeuf
2022-04-08 18:29 ` Masahiro Yamada
2022-04-08 19:14 ` Peter Zijlstra
2022-04-08 20:08 ` Nick Desaulniers
2022-04-08 20:16 ` Nick Desaulniers
2022-04-08 20:32 ` Peter Zijlstra
2022-04-08 20:48 ` Peter Zijlstra
2022-04-09 10:33 ` Arnd Bergmann [this message]
2022-04-09 0:48 ` Josh Poimboeuf
2022-04-20 17:03 ` Nick Desaulniers
2022-04-20 17:30 ` Josh Poimboeuf
2022-04-08 20:27 ` Nick Desaulniers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAK8P3a3xoUJ=aDROkWQ1Awpu0kiciohL7hJNsQ0Zn0K05bWObQ@mail.gmail.com' \
--to=arnd@arndb.de \
--cc=changbin.du@gmail.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=michal.lkml@markovi.net \
--cc=ndesaulniers@google.com \
--cc=peterz@infradead.org \
--cc=sam@ravnborg.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.