From: Peter Zijlstra <peterz@infradead.org>
To: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Nick Desaulniers <ndesaulniers@google.com>,
x86@kernel.org, hjl.tools@gmail.com, mbenes@suse.cz,
rostedt@goodmis.org, linux-toolchains@vger.kernel.org,
clang-built-linux <llvm@lists.linux.dev>
Subject: Re: The trouble with __weak and objtool got worse
Date: Sat, 16 Apr 2022 12:48:09 +0200 [thread overview]
Message-ID: <20220416104809.GC2731@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <20220415182130.iltk2uxnubeaa4nk@treble>
On Fri, Apr 15, 2022 at 11:21:30AM -0700, Josh Poimboeuf wrote:
> If LLVM assembler doesn't support this option then we may have to go
> with something like this? I can't seem to recreate so I'm not able to
> test.
>
> We'd also need some objtool checks to make sure the non-section-symbol
> fallback isn't being done for a weak symbol. Or just remove the
> fallback altogether and force section symbols whereever they're needed,
> similar to the below (untested).
>
>
> diff --git a/include/linux/static_call_types.h b/include/linux/static_call_types.h
> index 5a00b8b2cf9f..77040ce575fa 100644
> --- a/include/linux/static_call_types.h
> +++ b/include/linux/static_call_types.h
> @@ -52,9 +52,14 @@ struct static_call_site {
> #define __STATIC_CALL_ADDRESSABLE(name) \
> __ADDRESSABLE(STATIC_CALL_KEY(name))
>
> +extern unsigned long __addressable_ip;
> +
> +#define __STATIC_CALL_SITE_ADDRESSABLE() __addressable_ip = _THIS_IP_;
> +
> #define __static_call(name) \
> ({ \
> __STATIC_CALL_ADDRESSABLE(name); \
> + __STATIC_CALL_SITE_ADDRESSABLE(); \
> __raw_static_call(name); \
> })
>
> diff --git a/kernel/static_call_inline.c b/kernel/static_call_inline.c
> index dc5665b62814..f6e3e0463efb 100644
> --- a/kernel/static_call_inline.c
> +++ b/kernel/static_call_inline.c
> @@ -17,6 +17,8 @@ extern struct static_call_tramp_key __start_static_call_tramp_key[],
>
> static bool static_call_initialized;
>
> +unsigned long __section(".discard.addressable") __addressable_ip;
> +
> /* mutex to protect key modules/sites */
> static DEFINE_MUTEX(static_call_mutex);
This *might* work for static_call. But what about things like
.retpoline_sites?
If we get an indirect inside the weak function and at
a different place inside the non-weak function, then we end up with two
patch sites in the non-weak function.
And since all of that is compiler generated, we don't have anything to
stick anything in to alleviate trouble.
(in fact, I didn't observe this with static_call, I just picked it for
the example because it was somewhat easier)
next prev parent reply other threads:[~2022-04-16 10:48 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-15 11:19 The trouble with __weak and objtool got worse Peter Zijlstra
2022-04-15 14:12 ` Steven Rostedt
2022-04-15 15:31 ` Peter Zijlstra
2022-04-15 15:10 ` Josh Poimboeuf
2022-04-15 15:15 ` Josh Poimboeuf
2022-04-15 15:26 ` Peter Zijlstra
2022-04-15 17:40 ` Nick Desaulniers
2022-04-15 18:21 ` Josh Poimboeuf
2022-04-15 18:23 ` Josh Poimboeuf
2022-04-15 20:36 ` Nick Desaulniers
2022-04-16 10:49 ` Peter Zijlstra
2022-04-16 10:48 ` Peter Zijlstra [this message]
2022-04-16 16:07 ` Josh Poimboeuf
2022-04-16 16:32 ` H.J. Lu
2022-04-17 15:44 ` Peter Zijlstra
2022-04-17 15:46 ` Peter Zijlstra
2022-04-15 18:22 ` Segher Boessenkool
2022-04-15 18:36 ` Nick Desaulniers
2022-04-15 20:07 ` Segher Boessenkool
2022-04-15 20:31 ` Nick Desaulniers
2022-04-15 21:17 ` Fangrui Song
2022-04-15 21:41 ` Segher Boessenkool
2022-04-16 11:09 ` Peter Zijlstra
2022-04-16 10:59 ` Peter Zijlstra
2022-04-16 13:20 ` Segher Boessenkool
2022-04-16 17:59 ` Segher Boessenkool
2022-04-15 21:04 ` H.J. Lu
2022-04-16 11:25 ` Peter Zijlstra
2022-04-16 16:27 ` H.J. Lu
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=20220416104809.GC2731@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=hjl.tools@gmail.com \
--cc=jpoimboe@redhat.com \
--cc=linux-toolchains@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=mbenes@suse.cz \
--cc=ndesaulniers@google.com \
--cc=rostedt@goodmis.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.