From: "Chang S. Bae" <chang.seok.bae@intel.com>
To: Dave Hansen <dave.hansen@intel.com>, <jpoimboe@redhat.com>
Cc: <linux-kernel@vger.kernel.org>, <x86@kernel.org>,
<linux-pm@vger.kernel.org>, <tglx@linutronix.de>,
<peterz@infradead.org>, <bp@alien8.de>, <rafael@kernel.org>,
<ravi.v.shankar@intel.com>
Subject: Re: [PATCH v2 1/2] x86/fpu: Add a helper to prepare AMX state for low-power CPU idle
Date: Tue, 22 Mar 2022 00:05:31 -0700 [thread overview]
Message-ID: <aa3ff0f4-d74c-2c84-37c0-0880cabc0dd4@intel.com> (raw)
In-Reply-To: <13346402-7580-d60e-bb88-3172dd60406f@intel.com>
On 3/10/2022 1:00 PM, Chang S. Bae wrote:
>
> BTW, now I'm suspicious of this JMP as patched at runtime with
> fpu_state_size_dynamic():
No, this jump was supposed to be replaced with NOP by objtool but it
didn't as fail to interpret TILERELEASE in this case.
>
> 22: eb 01 jmp 0x25
> 24: c3 retq
> 25: b9 01 00 00 00 mov $0x1,%ecx
> 2a:* 0f 01 d0 xgetbv <-- trapping instruction
>
> Still, the question is, if so, why it was patched on non-XFD systems.
> Let me analyze the case a bit further with 0day folks.
>
Looks like 0day picked an internal branch where the instruction's opcode
was intentionally removed.
In practice, upstream code should accompany by a complete opcode table.
If it ever happens, a warning follows like this on build:
arch/x86/kernel/fpu/core.o: warning: objtool: can't decode
instruction at .text:0x185e
But what actually happened is barely indicated by this message alone.
This decode failure ends up returning check() immediately [1] so the
file is entirely skipped from the tool's process.
I came to think of some improvements for this tool:
(1) Add more messages like [2]. This may help users understand what
happens in this build process.
(2) Move on next byte from the failed offset like [3]. Perhaps, this
continuation may alleviate the impact. It may misinterpret some bytes
but I think it will be re-aligned with padding bytes before the next
function (symbol).
Include Josh Poimboeuf. Appreciate any feedback.
Thanks,
Chang
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/objtool/check.c#n3515
[2]:
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 7c33ec67c4a9..34b60fa33fbe 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -3507,27 +3507,27 @@ int check(struct objtool_file *file)
set_func_state(&func_cfi);
if (!cfi_hash_alloc(1UL << (file->elf->symbol_bits - 3)))
- goto out;
+ goto err;
cfi_hash_add(&init_cfi);
cfi_hash_add(&func_cfi);
ret = decode_sections(file);
if (ret < 0)
- goto out;
+ goto err;
warnings += ret;
if (list_empty(&file->insn_list))
- goto out;
+ return 0;
if (vmlinux && !validate_dup) {
ret = validate_vmlinux_functions(file);
if (ret < 0)
- goto out;
+ goto err;
warnings += ret;
- goto out;
+ return 0;
}
if (retpoline) {
@@ -3539,37 +3539,37 @@ int check(struct objtool_file *file)
ret = validate_functions(file);
if (ret < 0)
- goto out;
+ goto err;
warnings += ret;
ret = validate_unwind_hints(file, NULL);
if (ret < 0)
- goto out;
+ goto err;
warnings += ret;
if (!warnings) {
ret = validate_reachable_instructions(file);
if (ret < 0)
- goto out;
+ goto err;
warnings += ret;
}
ret = create_static_call_sections(file);
if (ret < 0)
- goto out;
+ goto err;
warnings += ret;
if (retpoline) {
ret = create_retpoline_sites_sections(file);
if (ret < 0)
- goto out;
+ goto err;
warnings += ret;
}
if (mcount) {
ret = create_mcount_loc_sections(file);
if (ret < 0)
- goto out;
+ goto err;
warnings += ret;
}
@@ -3580,11 +3580,14 @@ int check(struct objtool_file *file)
printf("nr_cfi_cache: %ld\n", nr_cfi_cache);
}
-out:
+ return 0;
+
+err:
/*
* For now, don't fail the kernel build on fatal warnings.These
* errors are still fairly common due to the growing matrix of
* supported toolchains and their recent pace of change.
*/
+ WARN("check failed - no jump_label instructions were written.");
return 0;
}
[3]:
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 7c33ec67c4a9..1f1515373ca5 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -371,7 +371,7 @@ static int decode_instructions(struct objtool_file
*file)
!strcmp(sec->name, ".entry.text"))
sec->noinstr = true;
- for (offset = 0; offset < sec->sh.sh_size; offset +=
insn->len) {
+ for (offset = 0; offset < sec->sh.sh_size;) {
insn = malloc(sizeof(*insn));
if (!insn) {
WARN("malloc failed");
@@ -389,12 +389,15 @@ static int decode_instructions(struct objtool_file
*file)
&insn->len,
&insn->type,
&insn->immediate,
&insn->stack_ops);
- if (ret)
- goto err;
+ if (ret) {
+ offset++;
+ continue;
+ }
hash_add(file->insn_hash, &insn->hash,
sec_offset_hash(sec, insn->offset));
list_add_tail(&insn->list, &file->insn_list);
nr_insns++;
+ offset += insn->len;
}
list_for_each_entry(func, &sec->symbol_list, list) {
@@ -416,10 +419,6 @@ static int decode_instructions(struct objtool_file
*file)
printf("nr_insns: %lu\n", nr_insns);
return 0;
-
-err:
- free(insn);
- return ret;
}
next prev parent reply other threads:[~2022-03-22 7:05 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-09 22:34 [PATCH v2 0/2] x86/fpu: Make AMX state ready for CPU idle Chang S. Bae
2022-03-09 22:34 ` [PATCH v2 1/2] x86/fpu: Add a helper to prepare AMX state for low-power " Chang S. Bae
2022-03-09 22:46 ` Dave Hansen
2022-03-09 23:12 ` Chang S. Bae
2022-03-10 0:24 ` Dave Hansen
2022-03-10 21:00 ` Chang S. Bae
2022-03-22 7:05 ` Chang S. Bae [this message]
2022-03-09 22:34 ` [PATCH v2 2/2] intel_idle: Add a new flag to initialize the AMX state Chang S. Bae
2022-03-10 18:34 ` Rafael J. Wysocki
2022-03-10 18:50 ` Chang S. Bae
2022-03-11 7:33 ` Artem Bityutskiy
2022-03-22 7:06 ` Chang S. Bae
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=aa3ff0f4-d74c-2c84-37c0-0880cabc0dd4@intel.com \
--to=chang.seok.bae@intel.com \
--cc=bp@alien8.de \
--cc=dave.hansen@intel.com \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=peterz@infradead.org \
--cc=rafael@kernel.org \
--cc=ravi.v.shankar@intel.com \
--cc=tglx@linutronix.de \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox