From: Peter Zijlstra <peterz@infradead.org>
To: tglx@linutronix.de, jpoimboe@redhat.com
Cc: linux-kernel@vger.kernel.org, x86@kernel.org,
mhiramat@kernel.org, mbenes@suse.cz
Subject: Re: [PATCH v4 01/13] objtool: Remove CFI save/restore special case
Date: Thu, 26 Mar 2020 12:30:49 +0100 [thread overview]
Message-ID: <20200326113049.GD20696@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <20200325174605.369570202@infradead.org>
On Wed, Mar 25, 2020 at 06:45:26PM +0100, Peter Zijlstra wrote:
> There is a special case in the UNWIND_HINT_RESTORE code. When, upon
> looking for the UNWIND_HINT_SAVE instruction to restore from, it finds
> the instruction hasn't been visited yet, it normally issues a WARN,
> except when this HINT_SAVE instruction is the first instruction of
> this branch.
>
> This special case is of dubious correctness and is certainly unused
> (verified with an allmodconfig build), the two sites that employ
> UNWIND_HINT_SAVE/RESTORE (sync_core() and ftrace_regs_caller()) have
> the SAVE on unconditional instructions at the start of the function.
> It is therefore impossible for the save_insn not to have been visited
> when we do hit the RESTORE.
Clearly I was too tired when I did that allmodconfig build, because it
very much does generate a warning :-/.
Thank you 0day:
kernel/sched/core.o: warning: objtool: finish_task_switch()+0x1c0: objtool isn't smart enough to handle this CFI save/restore combo
At least this gives clue as to what it was trying to do.
---
Subject: objtool: Remove CFI save/restore special case
From: Peter Zijlstra <peterz@infradead.org>
Date: Wed Mar 25 12:58:16 CET 2020
There is a special case in the UNWIND_HINT_RESTORE code. When, upon
looking for the UNWIND_HINT_SAVE instruction to restore from, it finds
the instruction hasn't been visited yet, it normally issues a WARN,
except when this HINT_SAVE instruction is the first instruction of
this branch.
The reason for this special case comes apparent when we remove it;
code like:
if (cond) {
UNWIND_HINT_SAVE
// do stuff
UNWIND_HINT_RESTORE
}
// more stuff
will now trigger the warning. This is because UNWIND_HINT_RESTORE is
just a label, and there is nothing keeping it inside the (extended)
basic block covered by @cond. It will attach itself to the first
instruction of 'more stuff' and we'll hit it outside of the @cond,
confusing things.
I don't much like this special case, it confuses things and will come
apart horribly if/when the annotation needs to support nesting.
Instead extend the affected code to at least form an extended basic
block.
In particular, of the 2 users of this annotation: ftrace_regs_caller()
and sync_core(), only the latter suffers this problem. Extend it's
code sequence with a NOP to make it an extended basic block.
This isn't ideal either; stuffing code with NOPs just to make
annotations work is certainly sub-optimal, but given that sync_core()
is stupid expensive in any case, one extra nop isn't going to be a
problem here.
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
---
arch/x86/include/asm/processor.h | 9 ++++++++-
tools/objtool/check.c | 15 ++-------------
2 files changed, 10 insertions(+), 14 deletions(-)
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -727,6 +727,13 @@ static inline void sync_core(void)
#else
unsigned int tmp;
+ /*
+ * The trailing NOP is required to make this an extended basic block,
+ * such that we can argue about it locally. Specifically this is
+ * important for the UNWIND_HINTs, without this the UNWIND_HINT_RESTORE
+ * can fall outside our extended basic block and objtool gets
+ * (rightfully) confused.
+ */
asm volatile (
UNWIND_HINT_SAVE
"mov %%ss, %0\n\t"
@@ -739,7 +746,7 @@ static inline void sync_core(void)
"pushq $1f\n\t"
"iretq\n\t"
UNWIND_HINT_RESTORE
- "1:"
+ "1: nop\n\t"
: "=&r" (tmp), ASM_CALL_CONSTRAINT : : "cc", "memory");
#endif
}
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -2000,15 +2000,14 @@ static int validate_sibling_call(struct
* tools/objtool/Documentation/stack-validation.txt.
*/
static int validate_branch(struct objtool_file *file, struct symbol *func,
- struct instruction *first, struct insn_state state)
+ struct instruction *insn, struct insn_state state)
{
+ struct instruction *next_insn;
struct alternative *alt;
- struct instruction *insn, *next_insn;
struct section *sec;
u8 visited;
int ret;
- insn = first;
sec = insn->sec;
if (insn->alt_group && list_empty(&insn->alts)) {
@@ -2061,16 +2060,6 @@ static int validate_branch(struct objtoo
}
if (!save_insn->visited) {
- /*
- * Oops, no state to copy yet.
- * Hopefully we can reach this
- * instruction from another branch
- * after the save insn has been
- * visited.
- */
- if (insn == first)
- return 0;
-
WARN_FUNC("objtool isn't smart enough to handle this CFI save/restore combo",
sec, insn->offset);
return 1;
next prev parent reply other threads:[~2020-03-26 11:30 UTC|newest]
Thread overview: 63+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-25 17:45 [PATCH v4 00/13] objtool: vmlinux.o and moinstr validation Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 01/13] objtool: Remove CFI save/restore special case Peter Zijlstra
2020-03-26 11:30 ` Peter Zijlstra [this message]
2020-03-26 12:58 ` Peter Zijlstra
2020-03-26 13:44 ` Josh Poimboeuf
2020-03-26 15:38 ` Peter Zijlstra
2020-03-27 4:19 ` Josh Poimboeuf
2020-03-26 14:44 ` Miroslav Benes
2020-03-26 15:04 ` Miroslav Benes
2020-03-26 13:00 ` Peter Zijlstra
2020-03-26 13:56 ` Josh Poimboeuf
2020-03-26 15:49 ` Peter Zijlstra
2020-03-26 19:57 ` Peter Zijlstra
2020-03-27 1:00 ` Josh Poimboeuf
2020-03-30 17:02 ` Peter Zijlstra
2020-03-30 19:02 ` Josh Poimboeuf
2020-03-30 20:02 ` Peter Zijlstra
2020-03-30 20:29 ` Peter Zijlstra
2020-03-31 11:16 ` [RFC][PATCH] objtool,ftrace: Implement UNWIND_HINT_RET_OFFSET Peter Zijlstra
2020-03-31 15:31 ` Steven Rostedt
2020-03-31 16:06 ` [RFC][PATCH] x86,ftrace: Shrink ftrace_regs_caller() by one byte Peter Zijlstra
2020-03-31 19:58 ` [RFC][PATCH] objtool,ftrace: Implement UNWIND_HINT_RET_OFFSET Peter Zijlstra
2020-03-31 20:26 ` Josh Poimboeuf
2020-03-31 20:23 ` Josh Poimboeuf
2020-03-31 20:40 ` Peter Zijlstra
2020-03-31 21:07 ` Peter Zijlstra
2020-03-31 21:17 ` Josh Poimboeuf
2020-03-31 21:20 ` Josh Poimboeuf
2020-03-31 22:27 ` [PATCH v2] " Peter Zijlstra
2020-04-01 14:14 ` Josh Poimboeuf
2020-04-01 14:22 ` Peter Zijlstra
2020-04-01 14:39 ` Josh Poimboeuf
2020-04-01 15:38 ` Peter Zijlstra
2020-04-01 15:39 ` Steven Rostedt
2020-04-01 15:43 ` Julien Thierry
2020-04-01 17:09 ` Peter Zijlstra
2020-04-01 17:33 ` Steven Rostedt
2020-04-01 17:45 ` Peter Zijlstra
2020-04-01 18:20 ` Steven Rostedt
2020-04-01 20:20 ` Peter Zijlstra
2020-04-01 17:37 ` Josh Poimboeuf
2020-04-02 6:41 ` Julien Thierry
2020-04-02 6:56 ` Julien Thierry
2020-04-02 7:50 ` Peter Zijlstra
2020-04-02 8:16 ` Julien Thierry
2020-04-02 8:17 ` Peter Zijlstra
2020-04-02 8:29 ` Julien Thierry
2020-04-02 8:58 ` Miroslav Benes
2020-03-25 17:45 ` [PATCH v4 02/13] objtool: Factor out CFI hints Peter Zijlstra
2020-03-25 18:26 ` Miroslav Benes
2020-03-25 19:41 ` Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 03/13] objtool: Rename struct cfi_state Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 04/13] objtool: Fix !CFI insn_state propagation Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 05/13] objtool: Implement noinstr validation Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 06/13] objtool: Optimize !vmlinux.o again Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 07/13] objtool: Use sec_offset_hash() for insn_hash Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 08/13] objtool: Detect loading function pointers across noinstr Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 09/13] kbuild/objtool: Add objtool-vmlinux.o pass Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 10/13] objtool: Avoid iterating !text section symbols Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 11/13] objtool: Rearrange validate_section() Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 12/13] objtool: Add STT_NOTYPE noinstr validation Peter Zijlstra
2020-03-25 17:45 ` [PATCH v4 13/13] objtool: Also consider .entry.text as noinstr Peter Zijlstra
2020-03-25 19:03 ` [PATCH v4 00/13] objtool: vmlinux.o and moinstr validation Miroslav Benes
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=20200326113049.GD20696@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=jpoimboe@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mbenes@suse.cz \
--cc=mhiramat@kernel.org \
--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
Powered by JetHome