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 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.