* [PATCH 1/2] x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*'
[not found] <20171013052544.euk7yawni47lhmdq@gmail.com>
@ 2017-10-13 20:02 ` Josh Poimboeuf
2017-10-14 10:49 ` [tip:x86/asm] " tip-bot for Josh Poimboeuf
2017-10-13 20:02 ` [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit Josh Poimboeuf
1 sibling, 1 reply; 19+ messages in thread
From: Josh Poimboeuf @ 2017-10-13 20:02 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, torvalds, peterz, hpa, tglx
Rename the unwinder config options from:
CONFIG_ORC_UNWINDER
CONFIG_FRAME_POINTER_UNWINDER
CONFIG_GUESS_UNWINDER
to:
CONFIG_UNWINDER_ORC
CONFIG_UNWINDER_FRAME_POINTER
CONFIG_UNWINDER_GUESS
... in order to give them a more logical config namespace.
Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
Documentation/x86/orc-unwinder.txt | 2 +-
Makefile | 4 ++--
arch/x86/Kconfig | 2 +-
arch/x86/Kconfig.debug | 10 +++++-----
arch/x86/configs/tiny.config | 4 ++--
arch/x86/configs/x86_64_defconfig | 2 +-
arch/x86/include/asm/module.h | 2 +-
arch/x86/include/asm/unwind.h | 8 ++++----
arch/x86/kernel/Makefile | 6 +++---
include/asm-generic/vmlinux.lds.h | 2 +-
lib/Kconfig.debug | 2 +-
scripts/Makefile.build | 2 +-
12 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/Documentation/x86/orc-unwinder.txt b/Documentation/x86/orc-unwinder.txt
index af0c9a4c65a6..cd4b29be29af 100644
--- a/Documentation/x86/orc-unwinder.txt
+++ b/Documentation/x86/orc-unwinder.txt
@@ -4,7 +4,7 @@ ORC unwinder
Overview
--------
-The kernel CONFIG_ORC_UNWINDER option enables the ORC unwinder, which is
+The kernel CONFIG_UNWINDER_ORC option enables the ORC unwinder, which is
similar in concept to a DWARF unwinder. The difference is that the
format of the ORC data is much simpler than DWARF, which in turn allows
the ORC unwinder to be much simpler and faster.
diff --git a/Makefile b/Makefile
index 5bf6fa4d62d8..1ef636bebccc 100644
--- a/Makefile
+++ b/Makefile
@@ -933,8 +933,8 @@ ifdef CONFIG_STACK_VALIDATION
ifeq ($(has_libelf),1)
objtool_target := tools/objtool FORCE
else
- ifdef CONFIG_ORC_UNWINDER
- $(error "Cannot generate ORC metadata for CONFIG_ORC_UNWINDER=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel")
+ ifdef CONFIG_UNWINDER_ORC
+ $(error "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel")
else
$(warning "Cannot use CONFIG_STACK_VALIDATION=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel")
endif
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 544273594c61..018556b375de 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -171,7 +171,7 @@ config X86
select HAVE_PERF_USER_STACK_DUMP
select HAVE_RCU_TABLE_FREE
select HAVE_REGS_AND_STACK_ACCESS_API
- select HAVE_RELIABLE_STACKTRACE if X86_64 && FRAME_POINTER_UNWINDER && STACK_VALIDATION
+ select HAVE_RELIABLE_STACKTRACE if X86_64 && UNWINDER_FRAME_POINTER && STACK_VALIDATION
select HAVE_STACK_VALIDATION if X86_64
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_UNSTABLE_SCHED_CLOCK
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 71a48a30fc84..f274dbb87c26 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -358,13 +358,13 @@ config PUNIT_ATOM_DEBUG
choice
prompt "Choose kernel unwinder"
- default FRAME_POINTER_UNWINDER
+ default UNWINDER_FRAME_POINTER
---help---
This determines which method will be used for unwinding kernel stack
traces for panics, oopses, bugs, warnings, perf, /proc/<pid>/stack,
livepatch, lockdep, and more.
-config FRAME_POINTER_UNWINDER
+config UNWINDER_FRAME_POINTER
bool "Frame pointer unwinder"
select FRAME_POINTER
---help---
@@ -379,7 +379,7 @@ config FRAME_POINTER_UNWINDER
consistency model, as this is currently the only way to get a
reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
-config ORC_UNWINDER
+config UNWINDER_ORC
bool "ORC unwinder"
depends on X86_64
select STACK_VALIDATION
@@ -395,7 +395,7 @@ config ORC_UNWINDER
Enabling this option will increase the kernel's runtime memory usage
by roughly 2-4MB, depending on your kernel config.
-config GUESS_UNWINDER
+config UNWINDER_GUESS
bool "Guess unwinder"
depends on EXPERT
---help---
@@ -410,7 +410,7 @@ config GUESS_UNWINDER
endchoice
config FRAME_POINTER
- depends on !ORC_UNWINDER && !GUESS_UNWINDER
+ depends on !UNWINDER_ORC && !UNWINDER_GUESS
bool
endmenu
diff --git a/arch/x86/configs/tiny.config b/arch/x86/configs/tiny.config
index 550cd5012b73..66c9e2aab16c 100644
--- a/arch/x86/configs/tiny.config
+++ b/arch/x86/configs/tiny.config
@@ -1,5 +1,5 @@
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
-CONFIG_GUESS_UNWINDER=y
-# CONFIG_FRAME_POINTER_UNWINDER is not set
+CONFIG_UNWINDER_GUESS=y
+# CONFIG_UNWINDER_FRAME_POINTER is not set
diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index eb65c248708d..e32fc1f274d8 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -299,7 +299,7 @@ CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_RODATA_TEST is not set
CONFIG_DEBUG_BOOT_PARAMS=y
CONFIG_OPTIMIZE_INLINING=y
-CONFIG_ORC_UNWINDER=y
+CONFIG_UNWINDER_ORC=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_SELINUX=y
diff --git a/arch/x86/include/asm/module.h b/arch/x86/include/asm/module.h
index 9eb7c718aaf8..9f05a1002aa9 100644
--- a/arch/x86/include/asm/module.h
+++ b/arch/x86/include/asm/module.h
@@ -5,7 +5,7 @@
#include <asm/orc_types.h>
struct mod_arch_specific {
-#ifdef CONFIG_ORC_UNWINDER
+#ifdef CONFIG_UNWINDER_ORC
unsigned int num_orcs;
int *orc_unwind_ip;
struct orc_entry *orc_unwind;
diff --git a/arch/x86/include/asm/unwind.h b/arch/x86/include/asm/unwind.h
index e9f793e2df7a..35d67dc7b69f 100644
--- a/arch/x86/include/asm/unwind.h
+++ b/arch/x86/include/asm/unwind.h
@@ -12,11 +12,11 @@ struct unwind_state {
struct task_struct *task;
int graph_idx;
bool error;
-#if defined(CONFIG_ORC_UNWINDER)
+#if defined(CONFIG_UNWINDER_ORC)
bool signal, full_regs;
unsigned long sp, bp, ip;
struct pt_regs *regs;
-#elif defined(CONFIG_FRAME_POINTER_UNWINDER)
+#elif defined(CONFIG_UNWINDER_FRAME_POINTER)
bool got_irq;
unsigned long *bp, *orig_sp, ip;
struct pt_regs *regs;
@@ -50,7 +50,7 @@ void unwind_start(struct unwind_state *state, struct task_struct *task,
__unwind_start(state, task, regs, first_frame);
}
-#if defined(CONFIG_ORC_UNWINDER) || defined(CONFIG_FRAME_POINTER_UNWINDER)
+#if defined(CONFIG_UNWINDER_ORC) || defined(CONFIG_UNWINDER_FRAME_POINTER)
static inline struct pt_regs *unwind_get_entry_regs(struct unwind_state *state)
{
if (unwind_done(state))
@@ -65,7 +65,7 @@ static inline struct pt_regs *unwind_get_entry_regs(struct unwind_state *state)
}
#endif
-#ifdef CONFIG_ORC_UNWINDER
+#ifdef CONFIG_UNWINDER_ORC
void unwind_init(void);
void unwind_module_init(struct module *mod, void *orc_ip, size_t orc_ip_size,
void *orc, size_t orc_size);
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index d8e2b700d1db..5335d05b695e 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -126,9 +126,9 @@ obj-$(CONFIG_PERF_EVENTS) += perf_regs.o
obj-$(CONFIG_TRACING) += tracepoint.o
obj-$(CONFIG_SCHED_MC_PRIO) += itmt.o
-obj-$(CONFIG_ORC_UNWINDER) += unwind_orc.o
-obj-$(CONFIG_FRAME_POINTER_UNWINDER) += unwind_frame.o
-obj-$(CONFIG_GUESS_UNWINDER) += unwind_guess.o
+obj-$(CONFIG_UNWINDER_ORC) += unwind_orc.o
+obj-$(CONFIG_UNWINDER_FRAME_POINTER) += unwind_frame.o
+obj-$(CONFIG_UNWINDER_GUESS) += unwind_guess.o
###
# 64 bit specific files
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index e549bff87c5b..353f52fdc35e 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -688,7 +688,7 @@
#define BUG_TABLE
#endif
-#ifdef CONFIG_ORC_UNWINDER
+#ifdef CONFIG_UNWINDER_ORC
#define ORC_UNWIND_TABLE \
. = ALIGN(4); \
.orc_unwind_ip : AT(ADDR(.orc_unwind_ip) - LOAD_OFFSET) { \
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index c6401d325b0e..01792bb77199 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -422,7 +422,7 @@ config STACK_VALIDATION
that runtime stack traces are more reliable.
This is also a prerequisite for generation of ORC unwind data, which
- is needed for CONFIG_ORC_UNWINDER.
+ is needed for CONFIG_UNWINDER_ORC.
For more information, see
tools/objtool/Documentation/stack-validation.txt.
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 061d0c3a420a..f965f477832e 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -258,7 +258,7 @@ ifneq ($(SKIP_STACK_VALIDATION),1)
__objtool_obj := $(objtree)/tools/objtool/objtool
-objtool_args = $(if $(CONFIG_ORC_UNWINDER),orc generate,check)
+objtool_args = $(if $(CONFIG_UNWINDER_ORC),orc generate,check)
ifndef CONFIG_FRAME_POINTER
objtool_args += --no-fp
--
2.13.6
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
[not found] <20171013052544.euk7yawni47lhmdq@gmail.com>
2017-10-13 20:02 ` [PATCH 1/2] x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*' Josh Poimboeuf
@ 2017-10-13 20:02 ` Josh Poimboeuf
2017-10-14 10:50 ` [tip:x86/asm] " tip-bot for Josh Poimboeuf
` (2 more replies)
1 sibling, 3 replies; 19+ messages in thread
From: Josh Poimboeuf @ 2017-10-13 20:02 UTC (permalink / raw)
To: Ingo Molnar; +Cc: linux-kernel, torvalds, peterz, hpa, tglx
The ORC unwinder has been stable in testing so far. Give it much wider
testing by making it the default in kconfig for x86_64. It's not yet
supported for 32-bit, so leave frame pointers as the default there.
Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
arch/x86/Kconfig.debug | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index f274dbb87c26..a4ff214fb760 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -358,27 +358,13 @@ config PUNIT_ATOM_DEBUG
choice
prompt "Choose kernel unwinder"
- default UNWINDER_FRAME_POINTER
+ default UNWINDER_ORC if X86_64
+ default UNWINDER_FRAME_POINTER if X86_32
---help---
This determines which method will be used for unwinding kernel stack
traces for panics, oopses, bugs, warnings, perf, /proc/<pid>/stack,
livepatch, lockdep, and more.
-config UNWINDER_FRAME_POINTER
- bool "Frame pointer unwinder"
- select FRAME_POINTER
- ---help---
- This option enables the frame pointer unwinder for unwinding kernel
- stack traces.
-
- The unwinder itself is fast and it uses less RAM than the ORC
- unwinder, but the kernel text size will grow by ~3% and the kernel's
- overall performance will degrade by roughly 5-10%.
-
- This option is recommended if you want to use the livepatch
- consistency model, as this is currently the only way to get a
- reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
-
config UNWINDER_ORC
bool "ORC unwinder"
depends on X86_64
@@ -395,6 +381,21 @@ config UNWINDER_ORC
Enabling this option will increase the kernel's runtime memory usage
by roughly 2-4MB, depending on your kernel config.
+config UNWINDER_FRAME_POINTER
+ bool "Frame pointer unwinder"
+ select FRAME_POINTER
+ ---help---
+ This option enables the frame pointer unwinder for unwinding kernel
+ stack traces.
+
+ The unwinder itself is fast and it uses less RAM than the ORC
+ unwinder, but the kernel text size will grow by ~3% and the kernel's
+ overall performance will degrade by roughly 5-10%.
+
+ This option is recommended if you want to use the livepatch
+ consistency model, as this is currently the only way to get a
+ reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
+
config UNWINDER_GUESS
bool "Guess unwinder"
depends on EXPERT
--
2.13.6
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [tip:x86/asm] x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*'
2017-10-13 20:02 ` [PATCH 1/2] x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*' Josh Poimboeuf
@ 2017-10-14 10:49 ` tip-bot for Josh Poimboeuf
0 siblings, 0 replies; 19+ messages in thread
From: tip-bot for Josh Poimboeuf @ 2017-10-14 10:49 UTC (permalink / raw)
To: linux-tip-commits
Cc: peterz, torvalds, mingo, hpa, jpoimboe, tglx, linux-kernel
Commit-ID: 11af847446ed0d131cf24d16a7ef3d5ea7a49554
Gitweb: https://git.kernel.org/tip/11af847446ed0d131cf24d16a7ef3d5ea7a49554
Author: Josh Poimboeuf <jpoimboe@redhat.com>
AuthorDate: Fri, 13 Oct 2017 15:02:00 -0500
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Sat, 14 Oct 2017 10:12:12 +0200
x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*'
Rename the unwinder config options from:
CONFIG_ORC_UNWINDER
CONFIG_FRAME_POINTER_UNWINDER
CONFIG_GUESS_UNWINDER
to:
CONFIG_UNWINDER_ORC
CONFIG_UNWINDER_FRAME_POINTER
CONFIG_UNWINDER_GUESS
... in order to give them a more logical config namespace.
Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/73972fc7e2762e91912c6b9584582703d6f1b8cc.1507924831.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
Documentation/x86/orc-unwinder.txt | 2 +-
Makefile | 4 ++--
arch/x86/Kconfig | 2 +-
arch/x86/Kconfig.debug | 10 +++++-----
arch/x86/configs/tiny.config | 4 ++--
arch/x86/configs/x86_64_defconfig | 2 +-
arch/x86/include/asm/module.h | 2 +-
arch/x86/include/asm/unwind.h | 8 ++++----
arch/x86/kernel/Makefile | 6 +++---
include/asm-generic/vmlinux.lds.h | 2 +-
lib/Kconfig.debug | 2 +-
scripts/Makefile.build | 2 +-
12 files changed, 23 insertions(+), 23 deletions(-)
diff --git a/Documentation/x86/orc-unwinder.txt b/Documentation/x86/orc-unwinder.txt
index af0c9a4..cd4b29b 100644
--- a/Documentation/x86/orc-unwinder.txt
+++ b/Documentation/x86/orc-unwinder.txt
@@ -4,7 +4,7 @@ ORC unwinder
Overview
--------
-The kernel CONFIG_ORC_UNWINDER option enables the ORC unwinder, which is
+The kernel CONFIG_UNWINDER_ORC option enables the ORC unwinder, which is
similar in concept to a DWARF unwinder. The difference is that the
format of the ORC data is much simpler than DWARF, which in turn allows
the ORC unwinder to be much simpler and faster.
diff --git a/Makefile b/Makefile
index bc5c79e..c0f723f 100644
--- a/Makefile
+++ b/Makefile
@@ -933,8 +933,8 @@ ifdef CONFIG_STACK_VALIDATION
ifeq ($(has_libelf),1)
objtool_target := tools/objtool FORCE
else
- ifdef CONFIG_ORC_UNWINDER
- $(error "Cannot generate ORC metadata for CONFIG_ORC_UNWINDER=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel")
+ ifdef CONFIG_UNWINDER_ORC
+ $(error "Cannot generate ORC metadata for CONFIG_UNWINDER_ORC=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel")
else
$(warning "Cannot use CONFIG_STACK_VALIDATION=y, please install libelf-dev, libelf-devel or elfutils-libelf-devel")
endif
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 971feac..6b94ca0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -170,7 +170,7 @@ config X86
select HAVE_PERF_USER_STACK_DUMP
select HAVE_RCU_TABLE_FREE
select HAVE_REGS_AND_STACK_ACCESS_API
- select HAVE_RELIABLE_STACKTRACE if X86_64 && FRAME_POINTER_UNWINDER && STACK_VALIDATION
+ select HAVE_RELIABLE_STACKTRACE if X86_64 && UNWINDER_FRAME_POINTER && STACK_VALIDATION
select HAVE_STACK_VALIDATION if X86_64
select HAVE_SYSCALL_TRACEPOINTS
select HAVE_UNSTABLE_SCHED_CLOCK
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index 71a48a3..f274dbb 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -358,13 +358,13 @@ config PUNIT_ATOM_DEBUG
choice
prompt "Choose kernel unwinder"
- default FRAME_POINTER_UNWINDER
+ default UNWINDER_FRAME_POINTER
---help---
This determines which method will be used for unwinding kernel stack
traces for panics, oopses, bugs, warnings, perf, /proc/<pid>/stack,
livepatch, lockdep, and more.
-config FRAME_POINTER_UNWINDER
+config UNWINDER_FRAME_POINTER
bool "Frame pointer unwinder"
select FRAME_POINTER
---help---
@@ -379,7 +379,7 @@ config FRAME_POINTER_UNWINDER
consistency model, as this is currently the only way to get a
reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
-config ORC_UNWINDER
+config UNWINDER_ORC
bool "ORC unwinder"
depends on X86_64
select STACK_VALIDATION
@@ -395,7 +395,7 @@ config ORC_UNWINDER
Enabling this option will increase the kernel's runtime memory usage
by roughly 2-4MB, depending on your kernel config.
-config GUESS_UNWINDER
+config UNWINDER_GUESS
bool "Guess unwinder"
depends on EXPERT
---help---
@@ -410,7 +410,7 @@ config GUESS_UNWINDER
endchoice
config FRAME_POINTER
- depends on !ORC_UNWINDER && !GUESS_UNWINDER
+ depends on !UNWINDER_ORC && !UNWINDER_GUESS
bool
endmenu
diff --git a/arch/x86/configs/tiny.config b/arch/x86/configs/tiny.config
index 550cd50..66c9e2a 100644
--- a/arch/x86/configs/tiny.config
+++ b/arch/x86/configs/tiny.config
@@ -1,5 +1,5 @@
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
-CONFIG_GUESS_UNWINDER=y
-# CONFIG_FRAME_POINTER_UNWINDER is not set
+CONFIG_UNWINDER_GUESS=y
+# CONFIG_UNWINDER_FRAME_POINTER is not set
diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig
index eb65c24..e32fc1f 100644
--- a/arch/x86/configs/x86_64_defconfig
+++ b/arch/x86/configs/x86_64_defconfig
@@ -299,7 +299,7 @@ CONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_RODATA_TEST is not set
CONFIG_DEBUG_BOOT_PARAMS=y
CONFIG_OPTIMIZE_INLINING=y
-CONFIG_ORC_UNWINDER=y
+CONFIG_UNWINDER_ORC=y
CONFIG_SECURITY=y
CONFIG_SECURITY_NETWORK=y
CONFIG_SECURITY_SELINUX=y
diff --git a/arch/x86/include/asm/module.h b/arch/x86/include/asm/module.h
index 9eb7c71..9f05a10 100644
--- a/arch/x86/include/asm/module.h
+++ b/arch/x86/include/asm/module.h
@@ -5,7 +5,7 @@
#include <asm/orc_types.h>
struct mod_arch_specific {
-#ifdef CONFIG_ORC_UNWINDER
+#ifdef CONFIG_UNWINDER_ORC
unsigned int num_orcs;
int *orc_unwind_ip;
struct orc_entry *orc_unwind;
diff --git a/arch/x86/include/asm/unwind.h b/arch/x86/include/asm/unwind.h
index e9f793e..35d67dc 100644
--- a/arch/x86/include/asm/unwind.h
+++ b/arch/x86/include/asm/unwind.h
@@ -12,11 +12,11 @@ struct unwind_state {
struct task_struct *task;
int graph_idx;
bool error;
-#if defined(CONFIG_ORC_UNWINDER)
+#if defined(CONFIG_UNWINDER_ORC)
bool signal, full_regs;
unsigned long sp, bp, ip;
struct pt_regs *regs;
-#elif defined(CONFIG_FRAME_POINTER_UNWINDER)
+#elif defined(CONFIG_UNWINDER_FRAME_POINTER)
bool got_irq;
unsigned long *bp, *orig_sp, ip;
struct pt_regs *regs;
@@ -50,7 +50,7 @@ void unwind_start(struct unwind_state *state, struct task_struct *task,
__unwind_start(state, task, regs, first_frame);
}
-#if defined(CONFIG_ORC_UNWINDER) || defined(CONFIG_FRAME_POINTER_UNWINDER)
+#if defined(CONFIG_UNWINDER_ORC) || defined(CONFIG_UNWINDER_FRAME_POINTER)
static inline struct pt_regs *unwind_get_entry_regs(struct unwind_state *state)
{
if (unwind_done(state))
@@ -65,7 +65,7 @@ static inline struct pt_regs *unwind_get_entry_regs(struct unwind_state *state)
}
#endif
-#ifdef CONFIG_ORC_UNWINDER
+#ifdef CONFIG_UNWINDER_ORC
void unwind_init(void);
void unwind_module_init(struct module *mod, void *orc_ip, size_t orc_ip_size,
void *orc, size_t orc_size);
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index fd0a789..6209ab6 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -127,9 +127,9 @@ obj-$(CONFIG_PERF_EVENTS) += perf_regs.o
obj-$(CONFIG_TRACING) += tracepoint.o
obj-$(CONFIG_SCHED_MC_PRIO) += itmt.o
-obj-$(CONFIG_ORC_UNWINDER) += unwind_orc.o
-obj-$(CONFIG_FRAME_POINTER_UNWINDER) += unwind_frame.o
-obj-$(CONFIG_GUESS_UNWINDER) += unwind_guess.o
+obj-$(CONFIG_UNWINDER_ORC) += unwind_orc.o
+obj-$(CONFIG_UNWINDER_FRAME_POINTER) += unwind_frame.o
+obj-$(CONFIG_UNWINDER_GUESS) += unwind_guess.o
###
# 64 bit specific files
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 8acfc1e..63e56f6 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -687,7 +687,7 @@
#define BUG_TABLE
#endif
-#ifdef CONFIG_ORC_UNWINDER
+#ifdef CONFIG_UNWINDER_ORC
#define ORC_UNWIND_TABLE \
. = ALIGN(4); \
.orc_unwind_ip : AT(ADDR(.orc_unwind_ip) - LOAD_OFFSET) { \
diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 2689b7c..7566eff 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -376,7 +376,7 @@ config STACK_VALIDATION
that runtime stack traces are more reliable.
This is also a prerequisite for generation of ORC unwind data, which
- is needed for CONFIG_ORC_UNWINDER.
+ is needed for CONFIG_UNWINDER_ORC.
For more information, see
tools/objtool/Documentation/stack-validation.txt.
diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 061d0c3..f965f47 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -258,7 +258,7 @@ ifneq ($(SKIP_STACK_VALIDATION),1)
__objtool_obj := $(objtree)/tools/objtool/objtool
-objtool_args = $(if $(CONFIG_ORC_UNWINDER),orc generate,check)
+objtool_args = $(if $(CONFIG_UNWINDER_ORC),orc generate,check)
ifndef CONFIG_FRAME_POINTER
objtool_args += --no-fp
^ permalink raw reply related [flat|nested] 19+ messages in thread
* [tip:x86/asm] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2017-10-13 20:02 ` [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit Josh Poimboeuf
@ 2017-10-14 10:50 ` tip-bot for Josh Poimboeuf
2017-10-19 16:51 ` [2/2] " Andrei Vagin
2018-03-19 18:57 ` [PATCH 2/2] " Matthias Kaehlcke
2 siblings, 0 replies; 19+ messages in thread
From: tip-bot for Josh Poimboeuf @ 2017-10-14 10:50 UTC (permalink / raw)
To: linux-tip-commits
Cc: peterz, tglx, hpa, mingo, jpoimboe, linux-kernel, torvalds
Commit-ID: fc72ae40e30327aa24eb88a24b9c7058f938bd36
Gitweb: https://git.kernel.org/tip/fc72ae40e30327aa24eb88a24b9c7058f938bd36
Author: Josh Poimboeuf <jpoimboe@redhat.com>
AuthorDate: Fri, 13 Oct 2017 15:02:01 -0500
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Sat, 14 Oct 2017 10:12:12 +0200
x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
The ORC unwinder has been stable in testing so far. Give it much wider
testing by making it the default in kconfig for x86_64. It's not yet
supported for 32-bit, so leave frame pointers as the default there.
Suggested-by: Ingo Molnar <mingo@kernel.org>
Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/9b1237bbe7244ed9cdf8db2dcb1253e37e1c341e.1507924831.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
arch/x86/Kconfig.debug | 33 +++++++++++++++++----------------
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
index f274dbb..a4ff214 100644
--- a/arch/x86/Kconfig.debug
+++ b/arch/x86/Kconfig.debug
@@ -358,27 +358,13 @@ config PUNIT_ATOM_DEBUG
choice
prompt "Choose kernel unwinder"
- default UNWINDER_FRAME_POINTER
+ default UNWINDER_ORC if X86_64
+ default UNWINDER_FRAME_POINTER if X86_32
---help---
This determines which method will be used for unwinding kernel stack
traces for panics, oopses, bugs, warnings, perf, /proc/<pid>/stack,
livepatch, lockdep, and more.
-config UNWINDER_FRAME_POINTER
- bool "Frame pointer unwinder"
- select FRAME_POINTER
- ---help---
- This option enables the frame pointer unwinder for unwinding kernel
- stack traces.
-
- The unwinder itself is fast and it uses less RAM than the ORC
- unwinder, but the kernel text size will grow by ~3% and the kernel's
- overall performance will degrade by roughly 5-10%.
-
- This option is recommended if you want to use the livepatch
- consistency model, as this is currently the only way to get a
- reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
-
config UNWINDER_ORC
bool "ORC unwinder"
depends on X86_64
@@ -395,6 +381,21 @@ config UNWINDER_ORC
Enabling this option will increase the kernel's runtime memory usage
by roughly 2-4MB, depending on your kernel config.
+config UNWINDER_FRAME_POINTER
+ bool "Frame pointer unwinder"
+ select FRAME_POINTER
+ ---help---
+ This option enables the frame pointer unwinder for unwinding kernel
+ stack traces.
+
+ The unwinder itself is fast and it uses less RAM than the ORC
+ unwinder, but the kernel text size will grow by ~3% and the kernel's
+ overall performance will degrade by roughly 5-10%.
+
+ This option is recommended if you want to use the livepatch
+ consistency model, as this is currently the only way to get a
+ reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
+
config UNWINDER_GUESS
bool "Guess unwinder"
depends on EXPERT
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2017-10-13 20:02 ` [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit Josh Poimboeuf
2017-10-14 10:50 ` [tip:x86/asm] " tip-bot for Josh Poimboeuf
@ 2017-10-19 16:51 ` Andrei Vagin
2017-10-19 18:16 ` Josh Poimboeuf
2018-03-19 18:57 ` [PATCH 2/2] " Matthias Kaehlcke
2 siblings, 1 reply; 19+ messages in thread
From: Andrei Vagin @ 2017-10-19 16:51 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
Hi,
We run CRIU tests for tip/auto-latest regularly, and a few days ago our
test job started to detect this warning in a kernel log:
[ 44.235786] WARNING: can't dereference iret registers at ffff8801c5f17fe0 for ip ffffffff95f0d94b
What does it mean? How critical is it?
Our test job fails if it detects any warning in a kernel log. Maybe we
need to investigate reasons of this warning and try to eliminate it?
Here are logs:
https://travis-ci.org/avagin/linux/jobs/289676634
Thanks,
Andrei
On Fri, Oct 13, 2017 at 03:02:01PM -0500, Josh Poimboeuf wrote:
> The ORC unwinder has been stable in testing so far. Give it much wider
> testing by making it the default in kconfig for x86_64. It's not yet
> supported for 32-bit, so leave frame pointers as the default there.
>
> Suggested-by: Ingo Molnar <mingo@kernel.org>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
> arch/x86/Kconfig.debug | 33 +++++++++++++++++----------------
> 1 file changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/arch/x86/Kconfig.debug b/arch/x86/Kconfig.debug
> index f274dbb87c26..a4ff214fb760 100644
> --- a/arch/x86/Kconfig.debug
> +++ b/arch/x86/Kconfig.debug
> @@ -358,27 +358,13 @@ config PUNIT_ATOM_DEBUG
>
> choice
> prompt "Choose kernel unwinder"
> - default UNWINDER_FRAME_POINTER
> + default UNWINDER_ORC if X86_64
> + default UNWINDER_FRAME_POINTER if X86_32
> ---help---
> This determines which method will be used for unwinding kernel stack
> traces for panics, oopses, bugs, warnings, perf, /proc/<pid>/stack,
> livepatch, lockdep, and more.
>
> -config UNWINDER_FRAME_POINTER
> - bool "Frame pointer unwinder"
> - select FRAME_POINTER
> - ---help---
> - This option enables the frame pointer unwinder for unwinding kernel
> - stack traces.
> -
> - The unwinder itself is fast and it uses less RAM than the ORC
> - unwinder, but the kernel text size will grow by ~3% and the kernel's
> - overall performance will degrade by roughly 5-10%.
> -
> - This option is recommended if you want to use the livepatch
> - consistency model, as this is currently the only way to get a
> - reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
> -
> config UNWINDER_ORC
> bool "ORC unwinder"
> depends on X86_64
> @@ -395,6 +381,21 @@ config UNWINDER_ORC
> Enabling this option will increase the kernel's runtime memory usage
> by roughly 2-4MB, depending on your kernel config.
>
> +config UNWINDER_FRAME_POINTER
> + bool "Frame pointer unwinder"
> + select FRAME_POINTER
> + ---help---
> + This option enables the frame pointer unwinder for unwinding kernel
> + stack traces.
> +
> + The unwinder itself is fast and it uses less RAM than the ORC
> + unwinder, but the kernel text size will grow by ~3% and the kernel's
> + overall performance will degrade by roughly 5-10%.
> +
> + This option is recommended if you want to use the livepatch
> + consistency model, as this is currently the only way to get a
> + reliable stack trace (CONFIG_HAVE_RELIABLE_STACKTRACE).
> +
> config UNWINDER_GUESS
> bool "Guess unwinder"
> depends on EXPERT
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2017-10-19 16:51 ` [2/2] " Andrei Vagin
@ 2017-10-19 18:16 ` Josh Poimboeuf
2017-10-19 22:35 ` Andrei Vagin
0 siblings, 1 reply; 19+ messages in thread
From: Josh Poimboeuf @ 2017-10-19 18:16 UTC (permalink / raw)
To: Andrei Vagin; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
On Thu, Oct 19, 2017 at 09:51:04AM -0700, Andrei Vagin wrote:
> Hi,
>
> We run CRIU tests for tip/auto-latest regularly, and a few days ago our
> test job started to detect this warning in a kernel log:
>
> [ 44.235786] WARNING: can't dereference iret registers at ffff8801c5f17fe0 for ip ffffffff95f0d94b
>
> What does it mean? How critical is it?
>
> Our test job fails if it detects any warning in a kernel log. Maybe we
> need to investigate reasons of this warning and try to eliminate it?
>
> Here are logs:
> https://travis-ci.org/avagin/linux/jobs/289676634
I think it means the unwinder found some bad ORC unwinder metadata. Any
chance you have access to the kernel binary? I need to know what code
corresponds to that ffffffff95f0d94b address.
Or if you can reproduce with the following patch, that should help:
diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
index 570b70d3f604..95b633f0ce51 100644
--- a/arch/x86/kernel/unwind_orc.c
+++ b/arch/x86/kernel/unwind_orc.c
@@ -448,7 +448,7 @@ bool unwind_next_frame(struct unwind_state *state)
case ORC_TYPE_REGS_IRET:
if (!deref_stack_regs(state, sp, &state->ip, &state->sp, false)) {
- orc_warn("can't dereference iret registers at %p for ip %p\n",
+ orc_warn("can't dereference iret registers at %p for ip %pB\n",
(void *)sp, (void *)orig_ip);
goto done;
}
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2017-10-19 18:16 ` Josh Poimboeuf
@ 2017-10-19 22:35 ` Andrei Vagin
2017-10-20 0:38 ` Andrei Vagin
2017-10-20 1:28 ` Josh Poimboeuf
0 siblings, 2 replies; 19+ messages in thread
From: Andrei Vagin @ 2017-10-19 22:35 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
On Thu, Oct 19, 2017 at 01:16:55PM -0500, Josh Poimboeuf wrote:
> On Thu, Oct 19, 2017 at 09:51:04AM -0700, Andrei Vagin wrote:
> > Hi,
> >
> > We run CRIU tests for tip/auto-latest regularly, and a few days ago our
> > test job started to detect this warning in a kernel log:
> >
> > [ 44.235786] WARNING: can't dereference iret registers at ffff8801c5f17fe0 for ip ffffffff95f0d94b
> >
> > What does it mean? How critical is it?
> >
> > Our test job fails if it detects any warning in a kernel log. Maybe we
> > need to investigate reasons of this warning and try to eliminate it?
> >
> > Here are logs:
> > https://travis-ci.org/avagin/linux/jobs/289676634
>
> I think it means the unwinder found some bad ORC unwinder metadata. Any
> chance you have access to the kernel binary? I need to know what code
> corresponds to that ffffffff95f0d94b address.
>
> Or if you can reproduce with the following patch, that should help:
>
>
> diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
> index 570b70d3f604..95b633f0ce51 100644
> --- a/arch/x86/kernel/unwind_orc.c
> +++ b/arch/x86/kernel/unwind_orc.c
> @@ -448,7 +448,7 @@ bool unwind_next_frame(struct unwind_state *state)
>
> case ORC_TYPE_REGS_IRET:
> if (!deref_stack_regs(state, sp, &state->ip, &state->sp, false)) {
> - orc_warn("can't dereference iret registers at %p for ip %p\n",
> + orc_warn("can't dereference iret registers at %p for ip %pB\n",
> (void *)sp, (void *)orig_ip);
> goto done;
> }
I applied your patch and rerun tests.
[ 44.947699] WARNING: can't dereference iret registers at ffff880178f5ffe0 for ip int3+0x5b/0x60
and now here is a warning from kasan:
[ 477.775676] ==================================================================
[ 477.775845] BUG: KASAN: stack-out-of-bounds in deref_stack_reg+0x11d/0x150
[ 477.775952] Read of size 8 at addr ffff880166b7fe90 by task make/16028
[ 477.776055]
[ 477.776149] CPU: 0 PID: 16028 Comm: make Not tainted 4.14.0-rc5+ #1
[ 477.776152] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
[ 477.776155] Call Trace:
[ 477.776159] <IRQ>
[ 477.776167] dump_stack+0x5c/0x7e
[ 477.776175] print_address_description+0x6b/0x290
[ 477.776182] ? deref_stack_reg+0x11d/0x150
[ 477.776186] kasan_report+0x25d/0x340
[ 477.776194] deref_stack_reg+0x11d/0x150
[ 477.776201] ? __read_once_size_nocheck.constprop.6+0x10/0x10
[ 477.776206] ? get_stack_info+0x37/0x170
[ 477.776212] ? stack_access_ok+0xdc/0x150
[ 477.776221] unwind_next_frame+0xe35/0x1c10
[ 477.776230] ? do_execveat_common.isra.34+0x78e/0x1890
[ 477.776238] ? deref_stack_reg+0x150/0x150
[ 477.776247] ? is_bpf_text_address+0x54/0x60
[ 477.776253] ? kernel_text_address+0xf4/0x100
[ 477.776257] ? do_execveat_common.isra.34+0x78e/0x1890
[ 477.776266] __save_stack_trace+0x73/0xd0
[ 477.776277] ? do_execveat_common.isra.34+0x78e/0x1890
[ 477.776285] save_stack+0x33/0xb0
[ 477.776291] ? kasan_slab_free+0x70/0xc0
[ 477.776298] ? kmem_cache_free+0x9f/0x230
[ 477.776303] ? rcu_process_callbacks+0x451/0xd60
[ 477.776307] ? __do_softirq+0x1d3/0x5e0
[ 477.776312] ? irq_exit+0x146/0x170
[ 477.776322] ? smp_apic_timer_interrupt+0x13e/0x3b0
[ 477.776326] ? apic_timer_interrupt+0x8c/0xa0
[ 477.776331] ? lock_acquire+0x6b/0x260
[ 477.776336] ? do_execveat_common.isra.34+0x78e/0x1890
[ 477.776347] ? update_curr+0x2d6/0x600
[ 477.776354] ? posix_cpu_timers_exit_group+0x50/0x50
[ 477.776365] ? trigger_load_balance+0x1fd/0x8a0
[ 477.776374] ? note_gp_changes+0x14e/0x1b0
[ 477.776384] ? lock_downgrade+0x590/0x590
[ 477.776389] ? rcu_accelerate_cbs+0x106/0x5e0
[ 477.776398] ? lock_acquire+0x113/0x260
[ 477.776402] ? rcu_process_callbacks+0x407/0xd60
[ 477.776407] kasan_slab_free+0x70/0xc0
[ 477.776414] ? rcu_process_callbacks+0x451/0xd60
[ 477.776418] kmem_cache_free+0x9f/0x230
[ 477.776425] ? free_inode_nonrcu+0x20/0x20
[ 477.776430] rcu_process_callbacks+0x451/0xd60
[ 477.776443] ? note_gp_changes+0x1b0/0x1b0
[ 477.776451] ? native_apic_msr_write+0x27/0x30
[ 477.776456] ? lapic_next_event+0x55/0x80
[ 477.776465] __do_softirq+0x1d3/0x5e0
[ 477.776479] ? do_execveat_common.isra.34+0x78e/0x1890
[ 477.776483] irq_exit+0x146/0x170
[ 477.776487] smp_apic_timer_interrupt+0x13e/0x3b0
[ 477.776494] apic_timer_interrupt+0x8c/0xa0
[ 477.776497] </IRQ>
[ 477.776502] RIP: 0010:lock_acquire+0x6b/0x260
[ 477.776505] RSP: 0018:ffff880166b7fd48 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff11
[ 477.776512] RAX: 0000000000000007 RBX: ffff8801c91cb080 RCX: 0000000000000000
[ 477.776515] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8801c91cb8b4
[ 477.776518] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
[ 477.776521] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
[ 477.776524] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff9f651fce
[ 477.776528] ? do_execveat_common.isra.34+0x78e/0x1890
[ 477.776552] do_execveat_common.isra.34+0x78e/0x1890
[ 477.776559] ? fs_reclaim_acquire.part.71+0x29/0x30
[ 477.776564] ? fs_reclaim_acquire.part.71+0x5/0x30
[ 477.776569] ? kmem_cache_alloc+0x29/0x1f0
[ 477.776577] ? do_execveat_common.isra.34+0x78e/0x1890
[ 477.776589] ? strncpy_from_user+0x74/0x260
[ 477.776595] ? prepare_bprm_creds+0x100/0x100
[ 477.776599] ? kmem_cache_alloc+0x18d/0x1f0
[ 477.776607] ? getname_flags+0xff/0x500
[ 477.776615] ? SyS_execve+0x2c/0x40
[ 477.776623] ? ptregs_sys_vfork+0x10/0x10
[ 477.776628] ? do_syscall_64+0x181/0x450
[ 477.776638] ? entry_SYSCALL64_slow_path+0x25/0x25
[ 477.776653]
[ 477.776747] The buggy address belongs to the page:
[ 477.776849] page:ffffea00059adfc0 count:0 mapcount:0 mapping: (null) index:0x0
[ 477.776968] flags: 0x17fff8000000000()
[ 477.777067] raw: 017fff8000000000 0000000000000000 0000000000000000 00000000ffffffff
[ 477.777184] raw: 0000000000000000 dead000000000200 0000000000000000 0000000000000000
[ 477.777298] page dumped because: kasan: bad access detected
[ 477.777404]
[ 477.777494] Memory state around the buggy address:
[ 477.777594] ffff880166b7fd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 477.777709] ffff880166b7fe00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
[ 477.777823] >ffff880166b7fe80: f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00
[ 477.777937] ^
[ 477.778034] ffff880166b7ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 477.778147] ffff880166b7ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[ 477.778260] ==================================================================
[ 477.778376] Disabling lock debugging due to kernel taint
All logs are here https://travis-ci.org/avagin/linux/jobs/290190646
Unfortunately vmlinux was not saved for this run. Thanks.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2017-10-19 22:35 ` Andrei Vagin
@ 2017-10-20 0:38 ` Andrei Vagin
2017-10-20 1:28 ` Josh Poimboeuf
1 sibling, 0 replies; 19+ messages in thread
From: Andrei Vagin @ 2017-10-20 0:38 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
On Thu, Oct 19, 2017 at 03:35:22PM -0700, Andrei Vagin wrote:
> On Thu, Oct 19, 2017 at 01:16:55PM -0500, Josh Poimboeuf wrote:
> > On Thu, Oct 19, 2017 at 09:51:04AM -0700, Andrei Vagin wrote:
> > > Hi,
> > >
> > > We run CRIU tests for tip/auto-latest regularly, and a few days ago our
> > > test job started to detect this warning in a kernel log:
> > >
> > > [ 44.235786] WARNING: can't dereference iret registers at ffff8801c5f17fe0 for ip ffffffff95f0d94b
> > >
> > > What does it mean? How critical is it?
> > >
> > > Our test job fails if it detects any warning in a kernel log. Maybe we
> > > need to investigate reasons of this warning and try to eliminate it?
> > >
> > > Here are logs:
> > > https://travis-ci.org/avagin/linux/jobs/289676634
> >
> > I think it means the unwinder found some bad ORC unwinder metadata. Any
> > chance you have access to the kernel binary? I need to know what code
> > corresponds to that ffffffff95f0d94b address.
> >
> > Or if you can reproduce with the following patch, that should help:
> >
> >
> > diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
> > index 570b70d3f604..95b633f0ce51 100644
> > --- a/arch/x86/kernel/unwind_orc.c
> > +++ b/arch/x86/kernel/unwind_orc.c
> > @@ -448,7 +448,7 @@ bool unwind_next_frame(struct unwind_state *state)
> >
> > case ORC_TYPE_REGS_IRET:
> > if (!deref_stack_regs(state, sp, &state->ip, &state->sp, false)) {
> > - orc_warn("can't dereference iret registers at %p for ip %p\n",
> > + orc_warn("can't dereference iret registers at %p for ip %pB\n",
> > (void *)sp, (void *)orig_ip);
> > goto done;
> > }
>
> I applied your patch and rerun tests.
>
> [ 44.947699] WARNING: can't dereference iret registers at ffff880178f5ffe0 for ip int3+0x5b/0x60
>
> and now here is a warning from kasan:
>
> [ 477.775676] ==================================================================
> [ 477.775845] BUG: KASAN: stack-out-of-bounds in deref_stack_reg+0x11d/0x150
> [ 477.775952] Read of size 8 at addr ffff880166b7fe90 by task make/16028
> [ 477.776055]
> [ 477.776149] CPU: 0 PID: 16028 Comm: make Not tainted 4.14.0-rc5+ #1
> [ 477.776152] Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
> [ 477.776155] Call Trace:
> [ 477.776159] <IRQ>
> [ 477.776167] dump_stack+0x5c/0x7e
> [ 477.776175] print_address_description+0x6b/0x290
> [ 477.776182] ? deref_stack_reg+0x11d/0x150
> [ 477.776186] kasan_report+0x25d/0x340
> [ 477.776194] deref_stack_reg+0x11d/0x150
> [ 477.776201] ? __read_once_size_nocheck.constprop.6+0x10/0x10
> [ 477.776206] ? get_stack_info+0x37/0x170
> [ 477.776212] ? stack_access_ok+0xdc/0x150
> [ 477.776221] unwind_next_frame+0xe35/0x1c10
> [ 477.776230] ? do_execveat_common.isra.34+0x78e/0x1890
> [ 477.776238] ? deref_stack_reg+0x150/0x150
> [ 477.776247] ? is_bpf_text_address+0x54/0x60
> [ 477.776253] ? kernel_text_address+0xf4/0x100
> [ 477.776257] ? do_execveat_common.isra.34+0x78e/0x1890
> [ 477.776266] __save_stack_trace+0x73/0xd0
> [ 477.776277] ? do_execveat_common.isra.34+0x78e/0x1890
> [ 477.776285] save_stack+0x33/0xb0
> [ 477.776291] ? kasan_slab_free+0x70/0xc0
> [ 477.776298] ? kmem_cache_free+0x9f/0x230
> [ 477.776303] ? rcu_process_callbacks+0x451/0xd60
> [ 477.776307] ? __do_softirq+0x1d3/0x5e0
> [ 477.776312] ? irq_exit+0x146/0x170
> [ 477.776322] ? smp_apic_timer_interrupt+0x13e/0x3b0
> [ 477.776326] ? apic_timer_interrupt+0x8c/0xa0
> [ 477.776331] ? lock_acquire+0x6b/0x260
> [ 477.776336] ? do_execveat_common.isra.34+0x78e/0x1890
> [ 477.776347] ? update_curr+0x2d6/0x600
> [ 477.776354] ? posix_cpu_timers_exit_group+0x50/0x50
> [ 477.776365] ? trigger_load_balance+0x1fd/0x8a0
> [ 477.776374] ? note_gp_changes+0x14e/0x1b0
> [ 477.776384] ? lock_downgrade+0x590/0x590
> [ 477.776389] ? rcu_accelerate_cbs+0x106/0x5e0
> [ 477.776398] ? lock_acquire+0x113/0x260
> [ 477.776402] ? rcu_process_callbacks+0x407/0xd60
> [ 477.776407] kasan_slab_free+0x70/0xc0
> [ 477.776414] ? rcu_process_callbacks+0x451/0xd60
> [ 477.776418] kmem_cache_free+0x9f/0x230
> [ 477.776425] ? free_inode_nonrcu+0x20/0x20
> [ 477.776430] rcu_process_callbacks+0x451/0xd60
> [ 477.776443] ? note_gp_changes+0x1b0/0x1b0
> [ 477.776451] ? native_apic_msr_write+0x27/0x30
> [ 477.776456] ? lapic_next_event+0x55/0x80
> [ 477.776465] __do_softirq+0x1d3/0x5e0
> [ 477.776479] ? do_execveat_common.isra.34+0x78e/0x1890
> [ 477.776483] irq_exit+0x146/0x170
> [ 477.776487] smp_apic_timer_interrupt+0x13e/0x3b0
> [ 477.776494] apic_timer_interrupt+0x8c/0xa0
> [ 477.776497] </IRQ>
> [ 477.776502] RIP: 0010:lock_acquire+0x6b/0x260
> [ 477.776505] RSP: 0018:ffff880166b7fd48 EFLAGS: 00000246 ORIG_RAX: ffffffffffffff11
> [ 477.776512] RAX: 0000000000000007 RBX: ffff8801c91cb080 RCX: 0000000000000000
> [ 477.776515] RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff8801c91cb8b4
> [ 477.776518] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
> [ 477.776521] R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
> [ 477.776524] R13: 0000000000000000 R14: 0000000000000000 R15: ffffffff9f651fce
> [ 477.776528] ? do_execveat_common.isra.34+0x78e/0x1890
> [ 477.776552] do_execveat_common.isra.34+0x78e/0x1890
> [ 477.776559] ? fs_reclaim_acquire.part.71+0x29/0x30
> [ 477.776564] ? fs_reclaim_acquire.part.71+0x5/0x30
> [ 477.776569] ? kmem_cache_alloc+0x29/0x1f0
> [ 477.776577] ? do_execveat_common.isra.34+0x78e/0x1890
> [ 477.776589] ? strncpy_from_user+0x74/0x260
> [ 477.776595] ? prepare_bprm_creds+0x100/0x100
> [ 477.776599] ? kmem_cache_alloc+0x18d/0x1f0
> [ 477.776607] ? getname_flags+0xff/0x500
> [ 477.776615] ? SyS_execve+0x2c/0x40
> [ 477.776623] ? ptregs_sys_vfork+0x10/0x10
> [ 477.776628] ? do_syscall_64+0x181/0x450
> [ 477.776638] ? entry_SYSCALL64_slow_path+0x25/0x25
> [ 477.776653]
> [ 477.776747] The buggy address belongs to the page:
> [ 477.776849] page:ffffea00059adfc0 count:0 mapcount:0 mapping: (null) index:0x0
> [ 477.776968] flags: 0x17fff8000000000()
> [ 477.777067] raw: 017fff8000000000 0000000000000000 0000000000000000 00000000ffffffff
> [ 477.777184] raw: 0000000000000000 dead000000000200 0000000000000000 0000000000000000
> [ 477.777298] page dumped because: kasan: bad access detected
> [ 477.777404]
> [ 477.777494] Memory state around the buggy address:
> [ 477.777594] ffff880166b7fd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 477.777709] ffff880166b7fe00: 00 00 00 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00
> [ 477.777823] >ffff880166b7fe80: f4 f4 f4 f3 f3 f3 f3 00 00 00 00 00 00 00 00 00
> [ 477.777937] ^
> [ 477.778034] ffff880166b7ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 477.778147] ffff880166b7ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> [ 477.778260] ==================================================================
> [ 477.778376] Disabling lock debugging due to kernel taint
>
> All logs are here https://travis-ci.org/avagin/linux/jobs/290190646
>
> Unfortunately vmlinux was not saved for this run. Thanks.
Here is vmlinux:
https://www.dropbox.com/s/e70u6oxxj4pwe2h/vmlinux?dl=0
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2017-10-19 22:35 ` Andrei Vagin
2017-10-20 0:38 ` Andrei Vagin
@ 2017-10-20 1:28 ` Josh Poimboeuf
2017-10-20 6:54 ` Andrei Vagin
1 sibling, 1 reply; 19+ messages in thread
From: Josh Poimboeuf @ 2017-10-20 1:28 UTC (permalink / raw)
To: Andrei Vagin; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
On Thu, Oct 19, 2017 at 03:35:22PM -0700, Andrei Vagin wrote:
> On Thu, Oct 19, 2017 at 01:16:55PM -0500, Josh Poimboeuf wrote:
> > On Thu, Oct 19, 2017 at 09:51:04AM -0700, Andrei Vagin wrote:
> > > Hi,
> > >
> > > We run CRIU tests for tip/auto-latest regularly, and a few days ago our
> > > test job started to detect this warning in a kernel log:
> > >
> > > [ 44.235786] WARNING: can't dereference iret registers at ffff8801c5f17fe0 for ip ffffffff95f0d94b
> > >
> > > What does it mean? How critical is it?
> > >
> > > Our test job fails if it detects any warning in a kernel log. Maybe we
> > > need to investigate reasons of this warning and try to eliminate it?
> > >
> > > Here are logs:
> > > https://travis-ci.org/avagin/linux/jobs/289676634
> >
> > I think it means the unwinder found some bad ORC unwinder metadata. Any
> > chance you have access to the kernel binary? I need to know what code
> > corresponds to that ffffffff95f0d94b address.
> >
> > Or if you can reproduce with the following patch, that should help:
> >
> >
> > diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
> > index 570b70d3f604..95b633f0ce51 100644
> > --- a/arch/x86/kernel/unwind_orc.c
> > +++ b/arch/x86/kernel/unwind_orc.c
> > @@ -448,7 +448,7 @@ bool unwind_next_frame(struct unwind_state *state)
> >
> > case ORC_TYPE_REGS_IRET:
> > if (!deref_stack_regs(state, sp, &state->ip, &state->sp, false)) {
> > - orc_warn("can't dereference iret registers at %p for ip %p\n",
> > + orc_warn("can't dereference iret registers at %p for ip %pB\n",
> > (void *)sp, (void *)orig_ip);
> > goto done;
> > }
>
> I applied your patch and rerun tests.
>
> [ 44.947699] WARNING: can't dereference iret registers at ffff880178f5ffe0 for ip int3+0x5b/0x60
Thanks, that was enough for me to figure it out. Can you test the below fix?
> and now here is a warning from kasan:
>
> [ 477.775676] ==================================================================
> [ 477.775845] BUG: KASAN: stack-out-of-bounds in deref_stack_reg+0x11d/0x150
The KASAN warning is a known issue for which the fix is a little more
complicated. v1 of the patch was here:
https://lkml.kernel.org/r/cover.1507128293.git.jpoimboe@redhat.com
diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index 49167258d587..f6cdb7a1455e 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -808,7 +808,7 @@ apicinterrupt IRQ_WORK_VECTOR irq_work_interrupt smp_irq_work_interrupt
.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
ENTRY(\sym)
- UNWIND_HINT_IRET_REGS offset=8
+ UNWIND_HINT_IRET_REGS offset=\has_error_code*8
/* Sanity check */
.if \shift_ist != -1 && \paranoid == 0
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2017-10-20 1:28 ` Josh Poimboeuf
@ 2017-10-20 6:54 ` Andrei Vagin
0 siblings, 0 replies; 19+ messages in thread
From: Andrei Vagin @ 2017-10-20 6:54 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
On Thu, Oct 19, 2017 at 08:28:04PM -0500, Josh Poimboeuf wrote:
> On Thu, Oct 19, 2017 at 03:35:22PM -0700, Andrei Vagin wrote:
> > On Thu, Oct 19, 2017 at 01:16:55PM -0500, Josh Poimboeuf wrote:
> > > On Thu, Oct 19, 2017 at 09:51:04AM -0700, Andrei Vagin wrote:
> > > > Hi,
> > > >
> > > > We run CRIU tests for tip/auto-latest regularly, and a few days ago our
> > > > test job started to detect this warning in a kernel log:
> > > >
> > > > [ 44.235786] WARNING: can't dereference iret registers at ffff8801c5f17fe0 for ip ffffffff95f0d94b
> > > >
> > > > What does it mean? How critical is it?
> > > >
> > > > Our test job fails if it detects any warning in a kernel log. Maybe we
> > > > need to investigate reasons of this warning and try to eliminate it?
> > > >
> > > > Here are logs:
> > > > https://travis-ci.org/avagin/linux/jobs/289676634
> > >
> > > I think it means the unwinder found some bad ORC unwinder metadata. Any
> > > chance you have access to the kernel binary? I need to know what code
> > > corresponds to that ffffffff95f0d94b address.
> > >
> > > Or if you can reproduce with the following patch, that should help:
> > >
> > >
> > > diff --git a/arch/x86/kernel/unwind_orc.c b/arch/x86/kernel/unwind_orc.c
> > > index 570b70d3f604..95b633f0ce51 100644
> > > --- a/arch/x86/kernel/unwind_orc.c
> > > +++ b/arch/x86/kernel/unwind_orc.c
> > > @@ -448,7 +448,7 @@ bool unwind_next_frame(struct unwind_state *state)
> > >
> > > case ORC_TYPE_REGS_IRET:
> > > if (!deref_stack_regs(state, sp, &state->ip, &state->sp, false)) {
> > > - orc_warn("can't dereference iret registers at %p for ip %p\n",
> > > + orc_warn("can't dereference iret registers at %p for ip %pB\n",
> > > (void *)sp, (void *)orig_ip);
> > > goto done;
> > > }
> >
> > I applied your patch and rerun tests.
> >
> > [ 44.947699] WARNING: can't dereference iret registers at ffff880178f5ffe0 for ip int3+0x5b/0x60
>
> Thanks, that was enough for me to figure it out. Can you test the below fix?
This patch works for me. I run tests a few times and they found nothing
suspicious.
Tested-by: Andrei Vagin <avagin@virtuozzo.com>
Thank you!
>
> > and now here is a warning from kasan:
> >
> > [ 477.775676] ==================================================================
> > [ 477.775845] BUG: KASAN: stack-out-of-bounds in deref_stack_reg+0x11d/0x150
>
> The KASAN warning is a known issue for which the fix is a little more
> complicated. v1 of the patch was here:
>
> https://lkml.kernel.org/r/cover.1507128293.git.jpoimboe@redhat.com
>
>
>
> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index 49167258d587..f6cdb7a1455e 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -808,7 +808,7 @@ apicinterrupt IRQ_WORK_VECTOR irq_work_interrupt smp_irq_work_interrupt
>
> .macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
> ENTRY(\sym)
> - UNWIND_HINT_IRET_REGS offset=8
> + UNWIND_HINT_IRET_REGS offset=\has_error_code*8
>
> /* Sanity check */
> .if \shift_ist != -1 && \paranoid == 0
>
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2017-10-13 20:02 ` [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit Josh Poimboeuf
2017-10-14 10:50 ` [tip:x86/asm] " tip-bot for Josh Poimboeuf
2017-10-19 16:51 ` [2/2] " Andrei Vagin
@ 2018-03-19 18:57 ` Matthias Kaehlcke
2018-03-19 19:29 ` Josh Poimboeuf
2 siblings, 1 reply; 19+ messages in thread
From: Matthias Kaehlcke @ 2018-03-19 18:57 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
Hi Josh,
El Fri, Oct 13, 2017 at 03:02:01PM -0500 Josh Poimboeuf ha dit:
> The ORC unwinder has been stable in testing so far. Give it much wider
> testing by making it the default in kconfig for x86_64. It's not yet
> supported for 32-bit, so leave frame pointers as the default there.
>
> Suggested-by: Ingo Molnar <mingo@kernel.org>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> ---
Building an upstream kernel with clang results in plenty of objtool
warnings like these:
drivers/gpu/drm/i915/dvo_ch7017.o: warning: objtool: ch7017_get_hw_state()+0x80: return with modified stack frame
CC drivers/gpu/drm/i915/i915_oa_cflgt2.o
...
CC drivers/gpu/drm/i915/intel_lpe_audio.o
drivers/gpu/drm/i915/i915_gpu_error.o: warning: objtool: i915_error_printf()+0x6c: return with modified stack frame
drivers/gpu/drm/i915/intel_display.o: warning: objtool: pipe_config_err()+0xa6: return with modified stack frame
Bisecting shows that the warnings are generated since the ORC unwinder
was made the default. Not sure if the issue is on the unwinder side
or clang.
Any ideas on what could be the problems?
Thanks
Matthias
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2018-03-19 18:57 ` [PATCH 2/2] " Matthias Kaehlcke
@ 2018-03-19 19:29 ` Josh Poimboeuf
2018-03-19 20:31 ` Matthias Kaehlcke
0 siblings, 1 reply; 19+ messages in thread
From: Josh Poimboeuf @ 2018-03-19 19:29 UTC (permalink / raw)
To: Matthias Kaehlcke; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
On Mon, Mar 19, 2018 at 11:57:32AM -0700, Matthias Kaehlcke wrote:
> Hi Josh,
>
> El Fri, Oct 13, 2017 at 03:02:01PM -0500 Josh Poimboeuf ha dit:
>
> > The ORC unwinder has been stable in testing so far. Give it much wider
> > testing by making it the default in kconfig for x86_64. It's not yet
> > supported for 32-bit, so leave frame pointers as the default there.
> >
> > Suggested-by: Ingo Molnar <mingo@kernel.org>
> > Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > ---
>
> Building an upstream kernel with clang results in plenty of objtool
> warnings like these:
>
> drivers/gpu/drm/i915/dvo_ch7017.o: warning: objtool: ch7017_get_hw_state()+0x80: return with modified stack frame
> CC drivers/gpu/drm/i915/i915_oa_cflgt2.o
> ...
> CC drivers/gpu/drm/i915/intel_lpe_audio.o
> drivers/gpu/drm/i915/i915_gpu_error.o: warning: objtool: i915_error_printf()+0x6c: return with modified stack frame
> drivers/gpu/drm/i915/intel_display.o: warning: objtool: pipe_config_err()+0xa6: return with modified stack frame
>
> Bisecting shows that the warnings are generated since the ORC unwinder
> was made the default. Not sure if the issue is on the unwinder side
> or clang.
>
> Any ideas on what could be the problems?
Hi Matthias,
The ORC unwinder relies on objtool, which reverse engineers the compiled
code. This is objtool's first exposure to clang, so I'm not at all
surprised if it's getting confused.
Send me one of the .o files and I can take a quick look to see how bad
it is, but I'm guessing it's going to be a lot of work to make objtool
compatible with clang (and unfortunately I won't have the bandwidth to
work on that in the near term.)
In the meantime I'd recommend that you use frame pointers (and
CONFIG_STACK_VALIDATION=n) for clang-compiled kernels.
--
Josh
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2018-03-19 19:29 ` Josh Poimboeuf
@ 2018-03-19 20:31 ` Matthias Kaehlcke
2018-03-19 21:20 ` Josh Poimboeuf
0 siblings, 1 reply; 19+ messages in thread
From: Matthias Kaehlcke @ 2018-03-19 20:31 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
[-- Attachment #1: Type: text/plain, Size: 2011 bytes --]
El Mon, Mar 19, 2018 at 02:29:10PM -0500 Josh Poimboeuf ha dit:
> On Mon, Mar 19, 2018 at 11:57:32AM -0700, Matthias Kaehlcke wrote:
> > Hi Josh,
> >
> > El Fri, Oct 13, 2017 at 03:02:01PM -0500 Josh Poimboeuf ha dit:
> >
> > > The ORC unwinder has been stable in testing so far. Give it much wider
> > > testing by making it the default in kconfig for x86_64. It's not yet
> > > supported for 32-bit, so leave frame pointers as the default there.
> > >
> > > Suggested-by: Ingo Molnar <mingo@kernel.org>
> > > Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
> > > ---
> >
> > Building an upstream kernel with clang results in plenty of objtool
> > warnings like these:
> >
> > drivers/gpu/drm/i915/dvo_ch7017.o: warning: objtool: ch7017_get_hw_state()+0x80: return with modified stack frame
> > CC drivers/gpu/drm/i915/i915_oa_cflgt2.o
> > ...
> > CC drivers/gpu/drm/i915/intel_lpe_audio.o
> > drivers/gpu/drm/i915/i915_gpu_error.o: warning: objtool: i915_error_printf()+0x6c: return with modified stack frame
> > drivers/gpu/drm/i915/intel_display.o: warning: objtool: pipe_config_err()+0xa6: return with modified stack frame
> >
> > Bisecting shows that the warnings are generated since the ORC unwinder
> > was made the default. Not sure if the issue is on the unwinder side
> > or clang.
> >
> > Any ideas on what could be the problems?
>
> Hi Matthias,
>
> The ORC unwinder relies on objtool, which reverse engineers the compiled
> code. This is objtool's first exposure to clang, so I'm not at all
> surprised if it's getting confused.
>
> Send me one of the .o files and I can take a quick look to see how bad
> it is, but I'm guessing it's going to be a lot of work to make objtool
> compatible with clang (and unfortunately I won't have the bandwidth to
> work on that in the near term.)
>
> In the meantime I'd recommend that you use frame pointers (and
> CONFIG_STACK_VALIDATION=n) for clang-compiled kernels.
Thanks for your assessment!
dvo_ch7017.o is attached.
[-- Attachment #2: dvo_ch7017.o --]
[-- Type: application/x-object, Size: 8960 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2018-03-19 20:31 ` Matthias Kaehlcke
@ 2018-03-19 21:20 ` Josh Poimboeuf
2018-03-19 23:22 ` Matthias Kaehlcke
0 siblings, 1 reply; 19+ messages in thread
From: Josh Poimboeuf @ 2018-03-19 21:20 UTC (permalink / raw)
To: Matthias Kaehlcke; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
On Mon, Mar 19, 2018 at 01:31:30PM -0700, Matthias Kaehlcke wrote:
> > The ORC unwinder relies on objtool, which reverse engineers the compiled
> > code. This is objtool's first exposure to clang, so I'm not at all
> > surprised if it's getting confused.
> >
> > Send me one of the .o files and I can take a quick look to see how bad
> > it is, but I'm guessing it's going to be a lot of work to make objtool
> > compatible with clang (and unfortunately I won't have the bandwidth to
> > work on that in the near term.)
> >
> > In the meantime I'd recommend that you use frame pointers (and
> > CONFIG_STACK_VALIDATION=n) for clang-compiled kernels.
>
> Thanks for your assessment!
>
> dvo_ch7017.o is attached.
Here's a (surprisingly easy) fix for this particular issue, though I'd
be shocked if there weren't a bunch more issues lurking elsewhere. Let
me know how it goes.
BTW, one thing I noticed in the .o file is that most of the functions'
stacks are aligned to 16 bytes. It might be worth checking if the clang
-mstack-alignment=8 option is getting set, and if so, if it's working
properly. Otherwise, with aligned stacks, the frame pointer is forced,
which defeats most of the benefits of ORC.
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 92b6a2c21631..f02df714c18e 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -1386,6 +1386,17 @@ static int update_insn_state(struct instruction *insn, struct insn_state *state)
state->vals[op->dest.reg].offset = -state->stack_size;
}
+ else if (op->src.reg == CFI_BP && op->dest.reg == CFI_SP &&
+ cfa->base == CFI_BP) {
+
+ /*
+ * mov %rbp, %rsp
+ *
+ * Restore the original stack pointer (clang).
+ */
+ state->stack_size = -state->regs[CFI_BP].offset;
+ }
+
else if (op->dest.reg == cfa->base) {
/* mov %reg, %rsp */
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2018-03-19 21:20 ` Josh Poimboeuf
@ 2018-03-19 23:22 ` Matthias Kaehlcke
2018-03-20 2:28 ` Josh Poimboeuf
2018-03-21 2:45 ` Josh Poimboeuf
0 siblings, 2 replies; 19+ messages in thread
From: Matthias Kaehlcke @ 2018-03-19 23:22 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
[-- Attachment #1: Type: text/plain, Size: 2554 bytes --]
El Mon, Mar 19, 2018 at 04:20:53PM -0500 Josh Poimboeuf ha dit:
> On Mon, Mar 19, 2018 at 01:31:30PM -0700, Matthias Kaehlcke wrote:
> > > The ORC unwinder relies on objtool, which reverse engineers the compiled
> > > code. This is objtool's first exposure to clang, so I'm not at all
> > > surprised if it's getting confused.
> > >
> > > Send me one of the .o files and I can take a quick look to see how bad
> > > it is, but I'm guessing it's going to be a lot of work to make objtool
> > > compatible with clang (and unfortunately I won't have the bandwidth to
> > > work on that in the near term.)
> > >
> > > In the meantime I'd recommend that you use frame pointers (and
> > > CONFIG_STACK_VALIDATION=n) for clang-compiled kernels.
> >
> > Thanks for your assessment!
> >
> > dvo_ch7017.o is attached.
>
> Here's a (surprisingly easy) fix for this particular issue, though I'd
> be shocked if there weren't a bunch more issues lurking elsewhere. Let
> me know how it goes.
Thanks for having a look, this fixes the vast majority of warnings in
a defconfig build!
The remaining warnings are:
arch/x86/mm/pti.o: warning: objtool: pti_init() falls through to next
function pti_user_pagetable_walk_pmd()
s/debugfs/file.o: warning: objtool: full_proxy_llseek() falls through to next function full_proxy_read()
fs/debugfs/file.o: warning: objtool: full_proxy_read() falls through to next function full_proxy_write()
fs/debugfs/file.o: warning: objtool: full_proxy_write() falls through to next function full_proxy_poll()
fs/debugfs/file.o: warning: objtool: full_proxy_poll() falls through to next function full_proxy_unlocked_ioctl()
fs/debugfs/file.o: warning: objtool: full_proxy_unlocked_ioctl() falls
through to next function fops_u8_open()
In all these functions it's an 'early' return that 'causes' the
warning.
Obviously I don't expect you to spend large amounts of time
investigating this, but should there be a similarily easy fix it would
be certainly welcome :)
> BTW, one thing I noticed in the .o file is that most of the functions'
> stacks are aligned to 16 bytes. It might be worth checking if the clang
> -mstack-alignment=8 option is getting set, and if so, if it's working
> properly. Otherwise, with aligned stacks, the frame pointer is forced,
> which defeats most of the benefits of ORC.
Thanks for pointing this out. I verified that -mstack-alignment=8 is
set. Do the "and $0xfffffffffffffff0,%rsp" instructions indicate the
stack alignment of 16 bytes? These are also present in the object file
generated by gcc.
[-- Attachment #2: pti.o --]
[-- Type: application/x-object, Size: 9176 bytes --]
[-- Attachment #3: file.o --]
[-- Type: application/x-object, Size: 65376 bytes --]
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2018-03-19 23:22 ` Matthias Kaehlcke
@ 2018-03-20 2:28 ` Josh Poimboeuf
2018-03-20 19:39 ` Matthias Kaehlcke
2018-03-21 2:45 ` Josh Poimboeuf
1 sibling, 1 reply; 19+ messages in thread
From: Josh Poimboeuf @ 2018-03-20 2:28 UTC (permalink / raw)
To: Matthias Kaehlcke; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
On Mon, Mar 19, 2018 at 04:22:55PM -0700, Matthias Kaehlcke wrote:
> > Here's a (surprisingly easy) fix for this particular issue, though I'd
> > be shocked if there weren't a bunch more issues lurking elsewhere. Let
> > me know how it goes.
>
> Thanks for having a look, this fixes the vast majority of warnings in
> a defconfig build!
Wow. Consider me shocked :-)
> The remaining warnings are:
>
> arch/x86/mm/pti.o: warning: objtool: pti_init() falls through to next
> function pti_user_pagetable_walk_pmd()
> s/debugfs/file.o: warning: objtool: full_proxy_llseek() falls through to next function full_proxy_read()
> fs/debugfs/file.o: warning: objtool: full_proxy_read() falls through to next function full_proxy_write()
> fs/debugfs/file.o: warning: objtool: full_proxy_write() falls through to next function full_proxy_poll()
> fs/debugfs/file.o: warning: objtool: full_proxy_poll() falls through to next function full_proxy_unlocked_ioctl()
> fs/debugfs/file.o: warning: objtool: full_proxy_unlocked_ioctl() falls through to next function fops_u8_open()
These all seem to be related to some weirdness with the UD2 instruction,
not necessarily an objtool issue per se.
Any chance this fixes some of the warnings? If not, I can try to build
with clang and look a little deeper.
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index ab4711c63601..315a8757b565 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -124,7 +124,12 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
# define ASM_UNREACHABLE
#endif
#ifndef unreachable
-# define unreachable() do { annotate_reachable(); do { } while (1); } while (0)
+#define unreachable() \
+ do { \
+ annotate_unreachable(); \
+ barrier_before_unreachable(); \
+ __builtin_unreachable(); \
+ } while (0)
#endif
/*
^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2018-03-20 2:28 ` Josh Poimboeuf
@ 2018-03-20 19:39 ` Matthias Kaehlcke
0 siblings, 0 replies; 19+ messages in thread
From: Matthias Kaehlcke @ 2018-03-20 19:39 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
El Mon, Mar 19, 2018 at 09:28:03PM -0500 Josh Poimboeuf ha dit:
> On Mon, Mar 19, 2018 at 04:22:55PM -0700, Matthias Kaehlcke wrote:
> > > Here's a (surprisingly easy) fix for this particular issue, though I'd
> > > be shocked if there weren't a bunch more issues lurking elsewhere. Let
> > > me know how it goes.
> >
> > Thanks for having a look, this fixes the vast majority of warnings in
> > a defconfig build!
>
> Wow. Consider me shocked :-)
>
> > The remaining warnings are:
> >
> > arch/x86/mm/pti.o: warning: objtool: pti_init() falls through to next
> > function pti_user_pagetable_walk_pmd()
> > s/debugfs/file.o: warning: objtool: full_proxy_llseek() falls through to next function full_proxy_read()
> > fs/debugfs/file.o: warning: objtool: full_proxy_read() falls through to next function full_proxy_write()
> > fs/debugfs/file.o: warning: objtool: full_proxy_write() falls through to next function full_proxy_poll()
> > fs/debugfs/file.o: warning: objtool: full_proxy_poll() falls through to next function full_proxy_unlocked_ioctl()
> > fs/debugfs/file.o: warning: objtool: full_proxy_unlocked_ioctl() falls through to next function fops_u8_open()
>
> These all seem to be related to some weirdness with the UD2 instruction,
> not necessarily an objtool issue per se.
>
> Any chance this fixes some of the warnings? If not, I can try to build
> with clang and look a little deeper.
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index ab4711c63601..315a8757b565 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -124,7 +124,12 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
> # define ASM_UNREACHABLE
> #endif
> #ifndef unreachable
> -# define unreachable() do { annotate_reachable(); do { } while (1); } while (0)
> +#define unreachable() \
> + do { \
> + annotate_unreachable(); \
> + barrier_before_unreachable(); \
> + __builtin_unreachable(); \
> + } while (0)
> #endif
Thanks, unfortunately negative on this one, all the warnings are still
generated.
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2018-03-19 23:22 ` Matthias Kaehlcke
2018-03-20 2:28 ` Josh Poimboeuf
@ 2018-03-21 2:45 ` Josh Poimboeuf
2018-03-21 21:19 ` Matthias Kaehlcke
1 sibling, 1 reply; 19+ messages in thread
From: Josh Poimboeuf @ 2018-03-21 2:45 UTC (permalink / raw)
To: Matthias Kaehlcke; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
On Mon, Mar 19, 2018 at 04:22:55PM -0700, Matthias Kaehlcke wrote:
> arch/x86/mm/pti.o: warning: objtool: pti_init() falls through to next
> function pti_user_pagetable_walk_pmd()
> s/debugfs/file.o: warning: objtool: full_proxy_llseek() falls through to next function full_proxy_read()
> fs/debugfs/file.o: warning: objtool: full_proxy_read() falls through to next function full_proxy_write()
> fs/debugfs/file.o: warning: objtool: full_proxy_write() falls through to next function full_proxy_poll()
> fs/debugfs/file.o: warning: objtool: full_proxy_poll() falls through to next function full_proxy_unlocked_ioctl()
> fs/debugfs/file.o: warning: objtool: full_proxy_unlocked_ioctl() falls
> through to next function fops_u8_open()
Ok, I did a little more digging. Surprise, these objtool warnings are
actually correct. Somehow the WARN macros are causing Clang to produce
bad code. In some cases, Clang is assuming that a WARN is "noreturn",
i.e. that the UD2 doesn't return from the exception.
As an example, here's the full_proxy_llseek() function and its compiled
code:
#define FULL_PROXY_FUNC(name, ret_type, filp, proto, args) \
static ret_type full_proxy_ ## name(proto) \
{ \
struct dentry *dentry = F_DENTRY(filp); \
const struct file_operations *real_fops; \
ret_type r; \
\
r = debugfs_file_get(dentry); \
if (unlikely(r)) \
return r; \
real_fops = debugfs_real_fops(filp); \
r = real_fops->name(args); \
debugfs_file_put(dentry); \
return r; \
}
FULL_PROXY_FUNC(llseek, loff_t, filp,
PROTO(struct file *filp, loff_t offset, int whence),
ARGS(filp, offset, whence));
0000000000000ca0 <full_proxy_llseek>:
ca0: 55 push %rbp
ca1: 41 57 push %r15
ca3: 41 56 push %r14
ca5: 53 push %rbx
ca6: 48 83 ec 10 sub $0x10,%rsp
caa: 41 89 d6 mov %edx,%r14d
cad: 49 89 f7 mov %rsi,%r15
cb0: 48 89 fd mov %rdi,%rbp
cb3: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
cba: 00 00
cbc: 48 89 44 24 08 mov %rax,0x8(%rsp)
cc1: 48 8b 5d 18 mov 0x18(%rbp),%rbx
cc5: 48 89 df mov %rbx,%rdi
cc8: e8 00 00 00 00 callq ccd <full_proxy_llseek+0x2d>
cc9: R_X86_64_PC32 debugfs_file_get-0x4
ccd: 85 c0 test %eax,%eax
ccf: 75 65 jne d36 <full_proxy_llseek+0x96>
cd1: 48 8b 45 18 mov 0x18(%rbp),%rax
cd5: 48 8b 40 78 mov 0x78(%rax),%rax
cd9: a8 01 test $0x1,%al
cdb: 75 63 jne d40 <full_proxy_llseek+0xa0>
...
d40: 0f 0b ud2
d42: 0f 1f 40 00 nopl 0x0(%rax)
d46: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
d4d: 00 00 00
0000000000000d50 <full_proxy_read>:
After the debugfs_file_get() call, the debugfs_real_fops() call is
inlined. Here it is:
const struct file_operations *debugfs_real_fops(const struct file *filp)
{
struct debugfs_fsdata *fsd = F_DENTRY(filp)->d_fsdata;
if ((unsigned long)fsd & DEBUGFS_FSDATA_IS_REAL_FOPS_BIT) {
/*
* Urgh, we've been called w/o a protecting
* debugfs_file_get().
*/
WARN_ON(1);
return NULL;
}
return fsd->real_fops;
}
The WARN_ON() is the UD2 at offset d40. Notice that, as objtool found,
it just falls through to the next function instead of "returning" to
full_proxy_llseek().
At first I thought this might be some kind of "optimization", since, if
you look closely, you'll see that the warning can never happen in this
situation. But no, I downloaded the Clang binary, changed the
if ((unsigned long)fsd & DEBUGFS_FSDATA_IS_REAL_FOPS_BIT) /* DEBUGFS_FSDATA_IS_REAL_FOPS_BIT == 1 */
to
if ((unsigned long)fsd & 0x2)
and still got the same issue.
Then I figured that Clang must be peeking into the inline asm, and is
assuming that UD2 is a dead end. But no, I changed ASM_UD2 to a 2-byte
NOP, and got the same issue.
So unless I'm missing some "undefined behavior", this looks like a Clang
bug to me. Somehow it doesn't like the WARN macros (but apparently only
in a small number of cases).
--
Josh
^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit
2018-03-21 2:45 ` Josh Poimboeuf
@ 2018-03-21 21:19 ` Matthias Kaehlcke
0 siblings, 0 replies; 19+ messages in thread
From: Matthias Kaehlcke @ 2018-03-21 21:19 UTC (permalink / raw)
To: Josh Poimboeuf; +Cc: Ingo Molnar, linux-kernel, torvalds, peterz, hpa, tglx
El Tue, Mar 20, 2018 at 09:45:07PM -0500 Josh Poimboeuf ha dit:
> On Mon, Mar 19, 2018 at 04:22:55PM -0700, Matthias Kaehlcke wrote:
> > arch/x86/mm/pti.o: warning: objtool: pti_init() falls through to next
> > function pti_user_pagetable_walk_pmd()
> > s/debugfs/file.o: warning: objtool: full_proxy_llseek() falls through to next function full_proxy_read()
> > fs/debugfs/file.o: warning: objtool: full_proxy_read() falls through to next function full_proxy_write()
> > fs/debugfs/file.o: warning: objtool: full_proxy_write() falls through to next function full_proxy_poll()
> > fs/debugfs/file.o: warning: objtool: full_proxy_poll() falls through to next function full_proxy_unlocked_ioctl()
> > fs/debugfs/file.o: warning: objtool: full_proxy_unlocked_ioctl() falls
> > through to next function fops_u8_open()
>
> Ok, I did a little more digging. Surprise, these objtool warnings are
> actually correct. Somehow the WARN macros are causing Clang to produce
> bad code. In some cases, Clang is assuming that a WARN is "noreturn",
> i.e. that the UD2 doesn't return from the exception.
>
> As an example, here's the full_proxy_llseek() function and its compiled
> code:
>
> #define FULL_PROXY_FUNC(name, ret_type, filp, proto, args) \
> static ret_type full_proxy_ ## name(proto) \
> { \
> struct dentry *dentry = F_DENTRY(filp); \
> const struct file_operations *real_fops; \
> ret_type r; \
> \
> r = debugfs_file_get(dentry); \
> if (unlikely(r)) \
> return r; \
> real_fops = debugfs_real_fops(filp); \
> r = real_fops->name(args); \
> debugfs_file_put(dentry); \
> return r; \
> }
>
> FULL_PROXY_FUNC(llseek, loff_t, filp,
> PROTO(struct file *filp, loff_t offset, int whence),
> ARGS(filp, offset, whence));
>
>
> 0000000000000ca0 <full_proxy_llseek>:
> ca0: 55 push %rbp
> ca1: 41 57 push %r15
> ca3: 41 56 push %r14
> ca5: 53 push %rbx
> ca6: 48 83 ec 10 sub $0x10,%rsp
> caa: 41 89 d6 mov %edx,%r14d
> cad: 49 89 f7 mov %rsi,%r15
> cb0: 48 89 fd mov %rdi,%rbp
> cb3: 65 48 8b 04 25 28 00 mov %gs:0x28,%rax
> cba: 00 00
> cbc: 48 89 44 24 08 mov %rax,0x8(%rsp)
> cc1: 48 8b 5d 18 mov 0x18(%rbp),%rbx
> cc5: 48 89 df mov %rbx,%rdi
> cc8: e8 00 00 00 00 callq ccd <full_proxy_llseek+0x2d>
> cc9: R_X86_64_PC32 debugfs_file_get-0x4
> ccd: 85 c0 test %eax,%eax
> ccf: 75 65 jne d36 <full_proxy_llseek+0x96>
> cd1: 48 8b 45 18 mov 0x18(%rbp),%rax
> cd5: 48 8b 40 78 mov 0x78(%rax),%rax
> cd9: a8 01 test $0x1,%al
> cdb: 75 63 jne d40 <full_proxy_llseek+0xa0>
> ...
> d40: 0f 0b ud2
> d42: 0f 1f 40 00 nopl 0x0(%rax)
> d46: 66 2e 0f 1f 84 00 00 nopw %cs:0x0(%rax,%rax,1)
> d4d: 00 00 00
>
> 0000000000000d50 <full_proxy_read>:
>
>
> After the debugfs_file_get() call, the debugfs_real_fops() call is
> inlined. Here it is:
>
> const struct file_operations *debugfs_real_fops(const struct file *filp)
> {
> struct debugfs_fsdata *fsd = F_DENTRY(filp)->d_fsdata;
>
> if ((unsigned long)fsd & DEBUGFS_FSDATA_IS_REAL_FOPS_BIT) {
> /*
> * Urgh, we've been called w/o a protecting
> * debugfs_file_get().
> */
> WARN_ON(1);
> return NULL;
> }
>
> return fsd->real_fops;
> }
>
> The WARN_ON() is the UD2 at offset d40. Notice that, as objtool found,
> it just falls through to the next function instead of "returning" to
> full_proxy_llseek().
>
>
> At first I thought this might be some kind of "optimization", since, if
> you look closely, you'll see that the warning can never happen in this
> situation. But no, I downloaded the Clang binary, changed the
>
> if ((unsigned long)fsd & DEBUGFS_FSDATA_IS_REAL_FOPS_BIT) /* DEBUGFS_FSDATA_IS_REAL_FOPS_BIT == 1 */
>
> to
>
> if ((unsigned long)fsd & 0x2)
>
> and still got the same issue.
>
>
> Then I figured that Clang must be peeking into the inline asm, and is
> assuming that UD2 is a dead end. But no, I changed ASM_UD2 to a 2-byte
> NOP, and got the same issue.
>
>
> So unless I'm missing some "undefined behavior", this looks like a Clang
> bug to me. Somehow it doesn't like the WARN macros (but apparently only
> in a small number of cases).
The behavior is indeed mysterious. Thanks for digging!
I'll see if our compiler folks can get to the bottom of this.
Could you send your fix for objtool that restores the original stack
pointer as an official patch?
Thanks
Matthias
^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2018-03-21 21:19 UTC | newest]
Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <20171013052544.euk7yawni47lhmdq@gmail.com>
2017-10-13 20:02 ` [PATCH 1/2] x86/unwind: Rename unwinder config options to 'CONFIG_UNWINDER_*' Josh Poimboeuf
2017-10-14 10:49 ` [tip:x86/asm] " tip-bot for Josh Poimboeuf
2017-10-13 20:02 ` [PATCH 2/2] x86/unwind: Make CONFIG_UNWINDER_ORC=y the default in kconfig for 64-bit Josh Poimboeuf
2017-10-14 10:50 ` [tip:x86/asm] " tip-bot for Josh Poimboeuf
2017-10-19 16:51 ` [2/2] " Andrei Vagin
2017-10-19 18:16 ` Josh Poimboeuf
2017-10-19 22:35 ` Andrei Vagin
2017-10-20 0:38 ` Andrei Vagin
2017-10-20 1:28 ` Josh Poimboeuf
2017-10-20 6:54 ` Andrei Vagin
2018-03-19 18:57 ` [PATCH 2/2] " Matthias Kaehlcke
2018-03-19 19:29 ` Josh Poimboeuf
2018-03-19 20:31 ` Matthias Kaehlcke
2018-03-19 21:20 ` Josh Poimboeuf
2018-03-19 23:22 ` Matthias Kaehlcke
2018-03-20 2:28 ` Josh Poimboeuf
2018-03-20 19:39 ` Matthias Kaehlcke
2018-03-21 2:45 ` Josh Poimboeuf
2018-03-21 21:19 ` Matthias Kaehlcke
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.