From: Peter Zijlstra <peterz@infradead.org>
To: x86@kernel.org
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org,
djwong@kernel.org, yujie.liu@intel.com, tglx@linutronix.de,
jpoimboe@kernel.org, joao.moreira@intel.com,
samitolvanen@google.com
Subject: [PATCH 1/5] kallsyms: Revert "Take callthunks into account"
Date: Fri, 28 Oct 2022 21:40:23 +0200 [thread overview]
Message-ID: <20221028194453.330970755@infradead.org> (raw)
In-Reply-To: <20221028194022.388521751@infradead.org>
This is a full revert of commit:
f1389181622a ("kallsyms: Take callthunks into account")
The commit assumes a number of things that are not quite right.
Notably it assumes every symbol has PADDING_BYTES in front of it that
are not claimed by another symbol.
This is not true; even when compiled with:
-fpatchable-function-entry=${PADDING_BYTES},${PADDING_BYTES}
Notably things like .cold subfunctions do not need to adhere to this
change in ABI. It it also not true when build with CFI_CLANG, which
claims these PADDING_BYTES in the __cfi_##name symbol.
Once the prefix bytes are not consistent and or otherwise claimed the
approach this patch takes goes out the window and kallsym resolution
will report invalid symbol names.
Therefore revert this to make room for another approach.
Reported-by: Reported-by: kernel test robot <yujie.liu@intel.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Link: https://lore.kernel.org/r/202210241614.2ae4c1f5-yujie.liu@intel.com
---
kernel/kallsyms.c | 45 +++++----------------------------------------
1 file changed, 5 insertions(+), 40 deletions(-)
--- a/kernel/kallsyms.c
+++ b/kernel/kallsyms.c
@@ -293,12 +293,6 @@ static unsigned long get_symbol_pos(unsi
return low;
}
-#ifdef CONFIG_FUNCTION_PADDING_BYTES
-#define PADDING_BYTES CONFIG_FUNCTION_PADDING_BYTES
-#else
-#define PADDING_BYTES 0
-#endif
-
/*
* Lookup an address but don't bother to find any names.
*/
@@ -306,25 +300,13 @@ int kallsyms_lookup_size_offset(unsigned
unsigned long *offset)
{
char namebuf[KSYM_NAME_LEN];
- int ret;
-
- addr += PADDING_BYTES;
if (is_ksym_addr(addr)) {
get_symbol_pos(addr, symbolsize, offset);
- ret = 1;
- goto found;
+ return 1;
}
-
- ret = !!module_address_lookup(addr, symbolsize, offset, NULL, NULL, namebuf);
- if (!ret) {
- ret = !!__bpf_address_lookup(addr, symbolsize,
- offset, namebuf);
- }
-found:
- if (ret && offset)
- *offset -= PADDING_BYTES;
- return ret;
+ return !!module_address_lookup(addr, symbolsize, offset, NULL, NULL, namebuf) ||
+ !!__bpf_address_lookup(addr, symbolsize, offset, namebuf);
}
static const char *kallsyms_lookup_buildid(unsigned long addr,
@@ -337,8 +319,6 @@ static const char *kallsyms_lookup_build
namebuf[KSYM_NAME_LEN - 1] = 0;
namebuf[0] = 0;
- addr += PADDING_BYTES;
-
if (is_ksym_addr(addr)) {
unsigned long pos;
@@ -368,8 +348,6 @@ static const char *kallsyms_lookup_build
found:
cleanup_symbol_name(namebuf);
- if (ret && offset)
- *offset -= PADDING_BYTES;
return ret;
}
@@ -396,8 +374,6 @@ int lookup_symbol_name(unsigned long add
symname[0] = '\0';
symname[KSYM_NAME_LEN - 1] = '\0';
- addr += PADDING_BYTES;
-
if (is_ksym_addr(addr)) {
unsigned long pos;
@@ -425,8 +401,6 @@ int lookup_symbol_attrs(unsigned long ad
name[0] = '\0';
name[KSYM_NAME_LEN - 1] = '\0';
- addr += PADDING_BYTES;
-
if (is_ksym_addr(addr)) {
unsigned long pos;
@@ -443,8 +417,6 @@ int lookup_symbol_attrs(unsigned long ad
return res;
found:
- if (offset)
- *offset -= PADDING_BYTES;
cleanup_symbol_name(name);
return 0;
}
@@ -470,15 +442,8 @@ static int __sprint_symbol(char *buffer,
len = strlen(buffer);
offset -= symbol_offset;
- if (add_offset) {
- char s = '+';
-
- if ((long)offset < 0) {
- s = '-';
- offset = 0UL - offset;
- }
- len += sprintf(buffer + len, "%c%#lx/%#lx", s, offset, size);
- }
+ if (add_offset)
+ len += sprintf(buffer + len, "+%#lx/%#lx", offset, size);
if (modname) {
len += sprintf(buffer + len, " [%s", modname);
next prev parent reply other threads:[~2022-10-28 19:48 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-10-28 19:40 [PATCH 0/5] x86/kallsyms: Fix the call-thunk kallsyms fail Peter Zijlstra
2022-10-28 19:40 ` Peter Zijlstra [this message]
2022-10-28 19:40 ` [PATCH 2/5] objtool: Slice up elf_create_section_symbol() Peter Zijlstra
2022-11-02 9:20 ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2022-10-28 19:40 ` [PATCH 3/5] objtool: Avoid O(bloody terrible) behaviour -- an ode to libelf Peter Zijlstra
2022-11-02 9:20 ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2022-11-02 22:22 ` [PATCH 3/5] " Josh Poimboeuf
2022-11-03 8:46 ` Peter Zijlstra
2022-10-28 19:40 ` [PATCH 4/5] objtool: Add option to generate prefix symbols Peter Zijlstra
2022-11-02 9:20 ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2022-11-02 23:41 ` [PATCH 4/5] " Josh Poimboeuf
2022-10-28 19:40 ` [PATCH 5/5] x86: Add prefix symbols for function padding Peter Zijlstra
2022-11-02 9:20 ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
2022-10-30 9:15 ` [PATCH 0/5] x86/kallsyms: Fix the call-thunk kallsyms fail Peter Zijlstra
2022-10-31 6:18 ` Yujie Liu
2022-11-02 21:46 ` [PATCH 6/5] objtool: Optimize elf_dirty_reloc_sym() Peter Zijlstra
2022-11-05 10:36 ` [tip: x86/core] " tip-bot2 for Peter Zijlstra
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=20221028194453.330970755@infradead.org \
--to=peterz@infradead.org \
--cc=djwong@kernel.org \
--cc=joao.moreira@intel.com \
--cc=jpoimboe@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=samitolvanen@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
--cc=yujie.liu@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®