All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH v2 0/4] Static calls
@ 2018-11-26 13:54 Josh Poimboeuf
  2018-11-26 13:54 ` [PATCH v2 1/4] compiler.h: Make __ADDRESSABLE() symbol truly unique Josh Poimboeuf
                   ` (8 more replies)
  0 siblings, 9 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 13:54 UTC (permalink / raw)
  To: x86
  Cc: linux-kernel, Ard Biesheuvel, Andy Lutomirski, Steven Rostedt,
	Peter Zijlstra, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

v2:
- fix STATIC_CALL_TRAMP() macro by using __PASTE() [Ard]
- rename optimized/unoptimized -> inline/out-of-line [Ard]
- tweak arch interfaces for PLT and add key->tramp field [Ard]
- rename 'poison' to 'defuse' and do it after all sites have been patched [Ard]
- fix .init handling [Ard, Steven]
- add CONFIG_HAVE_STATIC_CALL [Steven]
- make interfaces more consistent across configs to allow tracepoints to
  use them [Steven]
- move __ADDRESSABLE() to static_call() macro [Steven]
- prevent 2-byte jumps [Steven]
- add offset to asm-offsets.c instead of hard coding key->func offset
- add kernel_text_address() sanity check
- make __ADDRESSABLE() symbols truly unique

TODO:
- port Ard's arm64 patches to the new arch interfaces
- tracepoint performance testing

--------------------

These patches are related to two similar patch sets from Ard and Steve:

- https://lkml.kernel.org/r/20181005081333.15018-1-ard.biesheuvel@linaro.org
- https://lkml.kernel.org/r/20181006015110.653946300@goodmis.org

The code is also heavily inspired by the jump label code, as some of the
concepts are very similar.

There are three separate implementations, depending on what the arch
supports:

  1) CONFIG_HAVE_STATIC_CALL_INLINE: patched call sites - requires
     objtool and a small amount of arch code
  
  2) CONFIG_HAVE_STATIC_CALL_OUTLINE: patched trampolines - requires
     a small amount of arch code
  
  3) If no arch support, fall back to regular function pointers


Josh Poimboeuf (4):
  compiler.h: Make __ADDRESSABLE() symbol truly unique
  static_call: Add static call infrastructure
  x86/static_call: Add out-of-line static call implementation
  x86/static_call: Add inline static call implementation for x86-64

 arch/Kconfig                                  |  10 +
 arch/x86/Kconfig                              |   4 +-
 arch/x86/include/asm/static_call.h            |  52 +++
 arch/x86/kernel/Makefile                      |   1 +
 arch/x86/kernel/asm-offsets.c                 |   6 +
 arch/x86/kernel/static_call.c                 |  78 ++++
 include/asm-generic/vmlinux.lds.h             |  11 +
 include/linux/compiler.h                      |   2 +-
 include/linux/module.h                        |  10 +
 include/linux/static_call.h                   | 202 ++++++++++
 include/linux/static_call_types.h             |  19 +
 kernel/Makefile                               |   1 +
 kernel/module.c                               |   5 +
 kernel/static_call.c                          | 350 ++++++++++++++++++
 tools/objtool/Makefile                        |   3 +-
 tools/objtool/check.c                         | 126 ++++++-
 tools/objtool/check.h                         |   2 +
 tools/objtool/elf.h                           |   1 +
 .../objtool/include/linux/static_call_types.h |  19 +
 tools/objtool/sync-check.sh                   |   1 +
 20 files changed, 899 insertions(+), 4 deletions(-)
 create mode 100644 arch/x86/include/asm/static_call.h
 create mode 100644 arch/x86/kernel/static_call.c
 create mode 100644 include/linux/static_call.h
 create mode 100644 include/linux/static_call_types.h
 create mode 100644 kernel/static_call.c
 create mode 100644 tools/objtool/include/linux/static_call_types.h

-- 
2.17.2


^ permalink raw reply	[flat|nested] 120+ messages in thread

* [PATCH v2 1/4] compiler.h: Make __ADDRESSABLE() symbol truly unique
  2018-11-26 13:54 [PATCH v2 0/4] Static calls Josh Poimboeuf
@ 2018-11-26 13:54 ` Josh Poimboeuf
  2018-11-27  8:49   ` Ard Biesheuvel
  2018-11-26 13:54 ` [PATCH v2 2/4] static_call: Add static call infrastructure Josh Poimboeuf
                   ` (7 subsequent siblings)
  8 siblings, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 13:54 UTC (permalink / raw)
  To: x86
  Cc: linux-kernel, Ard Biesheuvel, Andy Lutomirski, Steven Rostedt,
	Peter Zijlstra, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

The __ADDRESSABLE() macro uses the __LINE__ macro to create a temporary
symbol which has a unique name.  However, if the macro is used multiple
times from within another macro, the line number will always be the
same, resulting in duplicate symbols.

Make the temporary symbols truly unique by using __UNIQUE_ID instead of
__LINE__.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 include/linux/compiler.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 06396c1cf127..4bb73fd918b5 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -282,7 +282,7 @@ unsigned long read_word_at_a_time(const void *addr)
  */
 #define __ADDRESSABLE(sym) \
 	static void * __section(".discard.addressable") __used \
-		__PASTE(__addressable_##sym, __LINE__) = (void *)&sym;
+		__UNIQUE_ID(__addressable_##sym) = (void *)&sym;
 
 /**
  * offset_to_ptr - convert a relative memory offset to an absolute pointer
-- 
2.17.2


^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [PATCH v2 2/4] static_call: Add static call infrastructure
  2018-11-26 13:54 [PATCH v2 0/4] Static calls Josh Poimboeuf
  2018-11-26 13:54 ` [PATCH v2 1/4] compiler.h: Make __ADDRESSABLE() symbol truly unique Josh Poimboeuf
@ 2018-11-26 13:54 ` Josh Poimboeuf
  2018-11-26 13:54 ` [PATCH v2 3/4] x86/static_call: Add out-of-line static call implementation Josh Poimboeuf
                   ` (6 subsequent siblings)
  8 siblings, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 13:54 UTC (permalink / raw)
  To: x86
  Cc: linux-kernel, Ard Biesheuvel, Andy Lutomirski, Steven Rostedt,
	Peter Zijlstra, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

Add a static call infrastructure.  Static calls use code patching to
hard-code function pointers into direct branch instructions.  They give
the flexibility of function pointers, but with improved performance.
This is especially important for cases where retpolines would otherwise
be used, as retpolines can significantly impact performance.

The concept and code are an extension of previous work done by Ard
Biesheuvel and Steven Rostedt:

  https://lkml.kernel.org/r/20181005081333.15018-1-ard.biesheuvel@linaro.org
  https://lkml.kernel.org/r/20181006015110.653946300@goodmis.org

This code is also heavily inspired by the jump label code (aka "static
jumps"), as some of the concepts are very similar.

There are three implementations, depending on arch support:

1) inline: patched call sites (CONFIG_HAVE_STATIC_CALL_INLINE)
2) out-of-line: patched trampolines (CONFIG_HAVE_STATIC_CALL_OUTLINE)
3) basic function pointers

For more details, see the comments in include/linux/static_call.h.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 arch/Kconfig                      |  10 +
 include/asm-generic/vmlinux.lds.h |  11 +
 include/linux/module.h            |  10 +
 include/linux/static_call.h       | 202 +++++++++++++++++
 include/linux/static_call_types.h |  19 ++
 kernel/Makefile                   |   1 +
 kernel/module.c                   |   5 +
 kernel/static_call.c              | 350 ++++++++++++++++++++++++++++++
 8 files changed, 608 insertions(+)
 create mode 100644 include/linux/static_call.h
 create mode 100644 include/linux/static_call_types.h
 create mode 100644 kernel/static_call.c

diff --git a/arch/Kconfig b/arch/Kconfig
index e1e540ffa979..4474f2958e03 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -879,6 +879,16 @@ config HAVE_ARCH_PREL32_RELOCATIONS
 	  architectures, and don't require runtime relocation on relocatable
 	  kernels.
 
+config HAVE_STATIC_CALL_INLINE
+	bool
+
+config HAVE_STATIC_CALL_OUTLINE
+	bool
+
+config HAVE_STATIC_CALL
+	def_bool y
+	depends on HAVE_STATIC_CALL_INLINE || HAVE_STATIC_CALL_OUTLINE
+
 source "kernel/gcov/Kconfig"
 
 source "scripts/gcc-plugins/Kconfig"
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 3d7a6a9c2370..f2729831c8b8 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -320,6 +320,7 @@
 	__start_ro_after_init = .;					\
 	*(.data..ro_after_init)						\
 	JUMP_TABLE_DATA							\
+	STATIC_CALL_SITES						\
 	__end_ro_after_init = .;
 #endif
 
@@ -725,6 +726,16 @@
 #define BUG_TABLE
 #endif
 
+#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
+#define STATIC_CALL_SITES						\
+	. = ALIGN(8);							\
+	__start_static_call_sites = .;					\
+	KEEP(*(.static_call_sites))					\
+	__stop_static_call_sites = .;
+#else
+#define STATIC_CALL_SITES
+#endif
+
 #ifdef CONFIG_UNWINDER_ORC
 #define ORC_UNWIND_TABLE						\
 	. = ALIGN(4);							\
diff --git a/include/linux/module.h b/include/linux/module.h
index fce6b4335e36..d7c575759931 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -21,6 +21,7 @@
 #include <linux/rbtree_latch.h>
 #include <linux/error-injection.h>
 #include <linux/tracepoint-defs.h>
+#include <linux/static_call_types.h>
 
 #include <linux/percpu.h>
 #include <asm/module.h>
@@ -450,6 +451,10 @@ struct module {
 	unsigned int num_ftrace_callsites;
 	unsigned long *ftrace_callsites;
 #endif
+#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
+	int num_static_call_sites;
+	struct static_call_site *static_call_sites;
+#endif
 
 #ifdef CONFIG_LIVEPATCH
 	bool klp; /* Is this a livepatch module? */
@@ -682,6 +687,11 @@ static inline bool is_module_text_address(unsigned long addr)
 	return false;
 }
 
+static inline bool within_module_init(unsigned long addr, const struct module *mod)
+{
+	return false;
+}
+
 /* Get/put a kernel symbol (calls should be symmetric) */
 #define symbol_get(x) ({ extern typeof(x) x __attribute__((weak)); &(x); })
 #define symbol_put(x) do { } while (0)
diff --git a/include/linux/static_call.h b/include/linux/static_call.h
new file mode 100644
index 000000000000..c8d0da1ef6b2
--- /dev/null
+++ b/include/linux/static_call.h
@@ -0,0 +1,202 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_STATIC_CALL_H
+#define _LINUX_STATIC_CALL_H
+
+/*
+ * Static call support
+ *
+ * Static calls use code patching to hard-code function pointers into direct
+ * branch instructions.  They give the flexibility of function pointers, but
+ * with improved performance.  This is especially important for cases where
+ * retpolines would otherwise be used, as retpolines can significantly impact
+ * performance.
+ *
+ *
+ * API overview:
+ *
+ *   DECLARE_STATIC_CALL(key, func);
+ *   DEFINE_STATIC_CALL(key, func);
+ *   static_call(key, args...);
+ *   static_call_update(key, func);
+ *
+ *
+ * Usage example:
+ *
+ *   # Start with the following functions (with identical prototypes):
+ *   int func_a(int arg1, int arg2);
+ *   int func_b(int arg1, int arg2);
+ *
+ *   # Define a 'my_key' reference, associated with func_a() by default
+ *   DEFINE_STATIC_CALL(my_key, func_a);
+ *
+ *   # Call func_a()
+ *   static_call(my_key, arg1, arg2);
+ *
+ *   # Update 'my_key' to point to func_b()
+ *   static_call_update(my_key, func_b);
+ *
+ *   # Call func_b()
+ *   static_call(my_key, arg1, arg2);
+ *
+ *
+ * Implementation details:
+ *
+ * There are three different implementations:
+ *
+ * 1) Inline static calls (patched call sites)
+ *
+ *    This requires objtool, which detects all the static_call() sites and
+ *    annotates them in the '.static_call_sites' section.  By default, the call
+ *    sites will call into a temporary per-key trampoline which has an indirect
+ *    branch to the current destination function associated with the key.
+ *    During system boot (or module init), all call sites are patched to call
+ *    their destination functions directly.  Updates to a key will patch all
+ *    call sites associated with that key.
+ *
+ * 2) Out-of-line static calls (patched trampolines)
+ *
+ *    Each static_call() site calls into a permanent trampoline associated with
+ *    the key.  The trampoline has a direct branch to the default function.
+ *    Updates to a key will modify the direct branch in the key's trampoline.
+ *
+ * 3) Generic implementation
+ *
+ *    This is the default implementation if the architecture hasn't implemented
+ *    static calls (either inline or out-of-line).  In this case, a basic
+ *    function pointer is used.
+ */
+
+#include <linux/types.h>
+#include <linux/cpu.h>
+#include <linux/static_call_types.h>
+
+#ifdef CONFIG_HAVE_STATIC_CALL
+#include <asm/static_call.h>
+extern void arch_static_call_transform(void *site, void *tramp, void *func);
+#endif
+
+
+#define DECLARE_STATIC_CALL(key, func)					\
+	extern struct static_call_key key;				\
+	extern typeof(func) STATIC_CALL_TRAMP(key)
+
+
+#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
+
+struct static_call_key {
+	void *func, *tramp;
+	/*
+	 * List of modules (including vmlinux) and their call sites associated
+	 * with this key.
+	 */
+	struct list_head site_mods;
+};
+
+struct static_call_mod {
+	struct list_head list;
+	struct module *mod; /* for vmlinux, mod == NULL */
+	struct static_call_site *sites;
+};
+
+extern void arch_static_call_defuse_tramp(void *site, void *tramp);
+extern void __static_call_update(struct static_call_key *key, void *func);
+extern int static_call_mod_init(struct module *mod);
+
+#define DEFINE_STATIC_CALL(key, _func)					\
+	DECLARE_STATIC_CALL(key, _func);				\
+	struct static_call_key key = {					\
+		.func = _func,						\
+		.tramp = STATIC_CALL_TRAMP(key),			\
+		.site_mods = LIST_HEAD_INIT(key.site_mods),		\
+	};								\
+	ARCH_DEFINE_STATIC_CALL_TRAMP(key, _func)
+
+/*
+ * __ADDRESSABLE() is used to ensure the key symbol doesn't get stripped from
+ * the symbol table so objtool can reference it when it generates the
+ * static_call_site structs.
+ */
+#define static_call(key, args...)					\
+({									\
+	__ADDRESSABLE(key);						\
+	STATIC_CALL_TRAMP(key)(args);					\
+})
+
+#define static_call_update(key, func)					\
+({									\
+	BUILD_BUG_ON(!__same_type(func, STATIC_CALL_TRAMP(key)));	\
+	__static_call_update(&key, func);				\
+})
+
+#define EXPORT_STATIC_CALL(key)						\
+	EXPORT_SYMBOL(key);						\
+	EXPORT_SYMBOL(STATIC_CALL_TRAMP(key))
+
+#define EXPORT_STATIC_CALL_GPL(key)					\
+	EXPORT_SYMBOL_GPL(key);						\
+	EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(key))
+
+
+#elif defined(CONFIG_HAVE_STATIC_CALL_OUTLINE)
+
+struct static_call_key {
+	void *func, *tramp;
+};
+
+#define DEFINE_STATIC_CALL(key, _func)					\
+	DECLARE_STATIC_CALL(key, _func);				\
+	struct static_call_key key = {					\
+		.func = _func,						\
+		.tramp = STATIC_CALL_TRAMP(key),			\
+	};								\
+	ARCH_DEFINE_STATIC_CALL_TRAMP(key, func)
+
+#define static_call(key, args...) STATIC_CALL_TRAMP(key)(args)
+
+#define __static_call_update(key, func)					\
+({									\
+	cpus_read_lock();						\
+	arch_static_call_transform(NULL, key->tramp, func);		\
+	cpus_read_unlock();						\
+})
+
+#define static_call_update(key, func)					\
+({									\
+	BUILD_BUG_ON(!__same_type(func, STATIC_CALL_TRAMP(key)));	\
+})
+
+#define EXPORT_STATIC_CALL(key)						\
+	EXPORT_SYMBOL(STATIC_CALL_TRAMP(key))
+
+#define EXPORT_STATIC_CALL_GPL(key)					\
+	EXPORT_SYMBOL_GPL(STATIC_CALL_TRAMP(key))
+
+
+#else /* Generic implementation */
+
+struct static_call_key {
+	void *func;
+};
+
+#define DEFINE_STATIC_CALL(key, _func)					\
+	DECLARE_STATIC_CALL(key, _func);				\
+	struct static_call_key key = {					\
+		.func = _func,						\
+	}
+
+#define static_call(key, args...)					\
+	((typeof(STATIC_CALL_TRAMP(key))*)(key.func))(args)
+
+#define __static_call_update(key, _func)				\
+	WRITE_ONCE(key->func, _func)
+
+#define static_call_update(key, func)					\
+	BUILD_BUG_ON(!__same_type(_func, STATIC_CALL_TRAMP(key)));	\
+	__static_call_update(key, func)
+
+#define EXPORT_STATIC_CALL(key) EXPORT_SYMBOL(key)
+#define EXPORT_STATIC_CALL_GPL(key) EXPORT_SYMBOL_GPL(key)
+
+#endif /* CONFIG_HAVE_STATIC_CALL_INLINE */
+
+#endif /* _LINUX_STATIC_CALL_H */
diff --git a/include/linux/static_call_types.h b/include/linux/static_call_types.h
new file mode 100644
index 000000000000..6859b208de6e
--- /dev/null
+++ b/include/linux/static_call_types.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _STATIC_CALL_TYPES_H
+#define _STATIC_CALL_TYPES_H
+
+#include <linux/stringify.h>
+
+#define STATIC_CALL_TRAMP_PREFIX ____static_call_tramp_
+#define STATIC_CALL_TRAMP_PREFIX_STR __stringify(STATIC_CALL_TRAMP_PREFIX)
+
+#define STATIC_CALL_TRAMP(key) __PASTE(STATIC_CALL_TRAMP_PREFIX, key)
+#define STATIC_CALL_TRAMP_STR(key) __stringify(STATIC_CALL_TRAMP(key))
+
+/* The static call site table is created by objtool. */
+struct static_call_site {
+	s32 addr;
+	s32 key;
+};
+
+#endif /* _STATIC_CALL_TYPES_H */
diff --git a/kernel/Makefile b/kernel/Makefile
index 7343b3a9bff0..88bc7fa14eb8 100644
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -103,6 +103,7 @@ obj-$(CONFIG_TRACEPOINTS) += trace/
 obj-$(CONFIG_IRQ_WORK) += irq_work.o
 obj-$(CONFIG_CPU_PM) += cpu_pm.o
 obj-$(CONFIG_BPF) += bpf/
+obj-$(CONFIG_HAVE_STATIC_CALL_INLINE) += static_call.o
 
 obj-$(CONFIG_PERF_EVENTS) += events/
 
diff --git a/kernel/module.c b/kernel/module.c
index 49a405891587..ecad0ee4ffb5 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -3121,6 +3121,11 @@ static int find_module_sections(struct module *mod, struct load_info *info)
 	mod->ei_funcs = section_objs(info, "_error_injection_whitelist",
 					    sizeof(*mod->ei_funcs),
 					    &mod->num_ei_funcs);
+#endif
+#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
+	mod->static_call_sites = section_objs(info, ".static_call_sites",
+					      sizeof(*mod->static_call_sites),
+					      &mod->num_static_call_sites);
 #endif
 	mod->extable = section_objs(info, "__ex_table",
 				    sizeof(*mod->extable), &mod->num_exentries);
diff --git a/kernel/static_call.c b/kernel/static_call.c
new file mode 100644
index 000000000000..88996ebe96e2
--- /dev/null
+++ b/kernel/static_call.c
@@ -0,0 +1,350 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/init.h>
+#include <linux/static_call.h>
+#include <linux/bug.h>
+#include <linux/smp.h>
+#include <linux/sort.h>
+#include <linux/slab.h>
+#include <linux/module.h>
+#include <linux/cpu.h>
+#include <linux/processor.h>
+#include <asm/sections.h>
+
+extern struct static_call_site __start_static_call_sites[],
+			       __stop_static_call_sites[];
+
+static bool static_call_initialized;
+
+#define STATIC_CALL_INIT 1UL
+
+/* mutex to protect key modules/sites */
+static DEFINE_MUTEX(static_call_mutex);
+
+static void static_call_lock(void)
+{
+	mutex_lock(&static_call_mutex);
+}
+
+static void static_call_unlock(void)
+{
+	mutex_unlock(&static_call_mutex);
+}
+
+static inline void *static_call_addr(struct static_call_site *site)
+{
+	return (void *)((long)site->addr + (long)&site->addr);
+}
+
+
+static inline struct static_call_key *static_call_key(const struct static_call_site *site)
+{
+	return (struct static_call_key *)
+		(((long)site->key + (long)&site->key) & ~STATIC_CALL_INIT);
+}
+
+/* These assume the key is word-aligned. */
+static inline bool static_call_is_init(struct static_call_site *site)
+{
+	return ((long)site->key + (long)&site->key) & STATIC_CALL_INIT;
+}
+
+static inline void static_call_set_init(struct static_call_site *site)
+{
+	site->key = ((long)static_call_key(site) | STATIC_CALL_INIT) -
+		    (long)&site->key;
+}
+
+static int static_call_site_cmp(const void *_a, const void *_b)
+{
+	const struct static_call_site *a = _a;
+	const struct static_call_site *b = _b;
+	const struct static_call_key *key_a = static_call_key(a);
+	const struct static_call_key *key_b = static_call_key(b);
+
+	if (key_a < key_b)
+		return -1;
+
+	if (key_a > key_b)
+		return 1;
+
+	return 0;
+}
+
+static void static_call_site_swap(void *_a, void *_b, int size)
+{
+	long delta = (unsigned long)_a - (unsigned long)_b;
+	struct static_call_site *a = _a;
+	struct static_call_site *b = _b;
+	struct static_call_site tmp = *a;
+
+	a->addr = b->addr  - delta;
+	a->key  = b->key   - delta;
+
+	b->addr = tmp.addr + delta;
+	b->key  = tmp.key  + delta;
+}
+
+static inline void static_call_sort_entries(struct static_call_site *start,
+					    struct static_call_site *stop)
+{
+	sort(start, stop - start, sizeof(struct static_call_site),
+	     static_call_site_cmp, static_call_site_swap);
+}
+
+void __static_call_update(struct static_call_key *key, void *func)
+{
+	struct static_call_mod *site_mod;
+	struct static_call_site *site, *stop;
+
+	cpus_read_lock();
+	static_call_lock();
+
+	if (key->func == func)
+		goto done;
+
+	key->func = func;
+
+	/*
+	 * If called before init, leave the call sites unpatched for now.
+	 * In the meantime they'll continue to call the temporary trampoline.
+	 */
+	if (!static_call_initialized)
+		goto done;
+
+	list_for_each_entry(site_mod, &key->site_mods, list) {
+		if (!site_mod->sites) {
+			/*
+			 * This can happen if the static call key is defined in
+			 * a module which doesn't use it.
+			 */
+			continue;
+		}
+
+		stop = __stop_static_call_sites;
+
+#ifdef CONFIG_MODULES
+		if (site_mod->mod) {
+			stop = site_mod->mod->static_call_sites +
+			       site_mod->mod->num_static_call_sites;
+		}
+#endif
+
+		for (site = site_mod->sites;
+		     site < stop && static_call_key(site) == key; site++) {
+			void *site_addr = static_call_addr(site);
+			struct module *mod = site_mod->mod;
+
+			if (static_call_is_init(site)) {
+				/*
+				 * Don't write to call sites which were in
+				 * initmem and have since been freed.
+				 */
+				if (!mod && system_state >= SYSTEM_RUNNING)
+					continue;
+				if (mod && (mod->state == MODULE_STATE_LIVE ||
+					    mod->state == MODULE_STATE_GOING))
+					continue;
+			}
+
+			if (!kernel_text_address((unsigned long)site_addr)) {
+				WARN_ONCE(1, "can't patch static call site at %pS",
+					  site_addr);
+				continue;
+			}
+
+			arch_static_call_transform(site_addr, key->tramp, func);
+		}
+	}
+
+done:
+	static_call_unlock();
+	cpus_read_unlock();
+}
+EXPORT_SYMBOL_GPL(__static_call_update);
+
+/*
+ * On arches without PLTs, the trampolines will no longer be used and can be
+ * poisoned.
+ *
+ * Other arches may continue to reuse the trampolines in cases where the
+ * destination function is too far away from the call site.
+ */
+static void static_call_defuse_tramps(struct static_call_site *start,
+				      struct static_call_site *stop)
+{
+	struct static_call_site *site;
+	struct static_call_key *key;
+	struct static_call_key *prev_key = NULL;
+
+	for (site = start; site < stop; site++) {
+		key = static_call_key(site);
+
+		if (key != prev_key) {
+			prev_key = key;
+			arch_static_call_defuse_tramp(static_call_addr(site),
+						      key->tramp);
+		}
+	}
+}
+
+#ifdef CONFIG_MODULES
+
+static int static_call_add_module(struct module *mod)
+{
+	struct static_call_site *start = mod->static_call_sites;
+	struct static_call_site *stop = mod->static_call_sites +
+					mod->num_static_call_sites;
+	struct static_call_site *site;
+	struct static_call_key *key, *prev_key = NULL;
+	struct static_call_mod *site_mod;
+
+	if (start == stop)
+		return 0;
+
+	static_call_sort_entries(start, stop);
+
+	for (site = start; site < stop; site++) {
+		void *site_addr = static_call_addr(site);
+
+		if (within_module_init((unsigned long)site_addr, mod))
+			static_call_set_init(site);
+
+		key = static_call_key(site);
+		if (key != prev_key) {
+			prev_key = key;
+
+			site_mod = kzalloc(sizeof(*site_mod), GFP_KERNEL);
+			if (!site_mod)
+				return -ENOMEM;
+
+			site_mod->mod = mod;
+			site_mod->sites = site;
+			list_add_tail(&site_mod->list, &key->site_mods);
+		}
+
+		arch_static_call_transform(site_addr, key->tramp, key->func);
+	}
+
+	/*
+	 * If a tramp is used across modules, it may be defused more than once.
+	 * This should be idempotent.
+	 */
+	static_call_defuse_tramps(start, stop);
+
+	return 0;
+}
+
+static void static_call_del_module(struct module *mod)
+{
+	struct static_call_site *start = mod->static_call_sites;
+	struct static_call_site *stop = mod->static_call_sites +
+					mod->num_static_call_sites;
+	struct static_call_site *site;
+	struct static_call_key *key, *prev_key = NULL;
+	struct static_call_mod *site_mod;
+
+	for (site = start; site < stop; site++) {
+		key = static_call_key(site);
+		if (key == prev_key)
+			continue;
+		prev_key = key;
+
+		list_for_each_entry(site_mod, &key->site_mods, list) {
+			if (site_mod->mod == mod) {
+				list_del(&site_mod->list);
+				kfree(site_mod);
+				break;
+			}
+		}
+	}
+}
+
+static int static_call_module_notify(struct notifier_block *nb,
+				     unsigned long val, void *data)
+{
+	struct module *mod = data;
+	int ret = 0;
+
+	cpus_read_lock();
+	static_call_lock();
+
+	switch (val) {
+	case MODULE_STATE_COMING:
+		module_disable_ro(mod);
+		ret = static_call_add_module(mod);
+		module_enable_ro(mod, false);
+		if (ret) {
+			WARN(1, "Failed to allocate memory for static calls");
+			static_call_del_module(mod);
+		}
+		break;
+	case MODULE_STATE_GOING:
+		static_call_del_module(mod);
+		break;
+	}
+
+	static_call_unlock();
+	cpus_read_unlock();
+
+	return notifier_from_errno(ret);
+}
+
+static struct notifier_block static_call_module_nb = {
+	.notifier_call = static_call_module_notify,
+};
+
+#endif /* CONFIG_MODULES */
+
+static void __init static_call_init(void)
+{
+	struct static_call_site *start = __start_static_call_sites;
+	struct static_call_site *stop  = __stop_static_call_sites;
+	struct static_call_site *site;
+
+	if (start == stop) {
+		pr_warn("WARNING: empty static call table\n");
+		return;
+	}
+
+	cpus_read_lock();
+	static_call_lock();
+
+	static_call_sort_entries(start, stop);
+
+	for (site = start; site < stop; site++) {
+		struct static_call_key *key = static_call_key(site);
+		void *site_addr = static_call_addr(site);
+
+		if (init_section_contains(site_addr, 1))
+			static_call_set_init(site);
+
+		if (list_empty(&key->site_mods)) {
+			struct static_call_mod *site_mod;
+
+			site_mod = kzalloc(sizeof(*site_mod), GFP_KERNEL);
+			if (!site_mod) {
+				WARN(1, "Failed to allocate memory for static calls");
+				goto done;
+			}
+
+			site_mod->sites = site;
+			list_add_tail(&site_mod->list, &key->site_mods);
+		}
+
+		arch_static_call_transform(site_addr, key->tramp, key->func);
+	}
+
+	static_call_defuse_tramps(start, stop);
+
+	static_call_initialized = true;
+
+done:
+	static_call_unlock();
+	cpus_read_unlock();
+
+#ifdef CONFIG_MODULES
+	if (static_call_initialized)
+		register_module_notifier(&static_call_module_nb);
+#endif
+}
+early_initcall(static_call_init);
-- 
2.17.2


^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [PATCH v2 3/4] x86/static_call: Add out-of-line static call implementation
  2018-11-26 13:54 [PATCH v2 0/4] Static calls Josh Poimboeuf
  2018-11-26 13:54 ` [PATCH v2 1/4] compiler.h: Make __ADDRESSABLE() symbol truly unique Josh Poimboeuf
  2018-11-26 13:54 ` [PATCH v2 2/4] static_call: Add static call infrastructure Josh Poimboeuf
@ 2018-11-26 13:54 ` Josh Poimboeuf
  2018-11-26 15:43   ` Peter Zijlstra
  2018-11-26 13:55 ` [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64 Josh Poimboeuf
                   ` (5 subsequent siblings)
  8 siblings, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 13:54 UTC (permalink / raw)
  To: x86
  Cc: linux-kernel, Ard Biesheuvel, Andy Lutomirski, Steven Rostedt,
	Peter Zijlstra, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

Add the x86 out-of-line static call implementation.  For each key, a
permanent trampoline is created which is the destination for all static
calls for the given key.  The trampoline has a direct jump which gets
patched by static_call_update() when the destination function changes.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 arch/x86/Kconfig                   |  1 +
 arch/x86/include/asm/static_call.h | 28 ++++++++++++++++
 arch/x86/kernel/Makefile           |  1 +
 arch/x86/kernel/static_call.c      | 54 ++++++++++++++++++++++++++++++
 include/linux/static_call.h        |  2 +-
 5 files changed, 85 insertions(+), 1 deletion(-)
 create mode 100644 arch/x86/include/asm/static_call.h
 create mode 100644 arch/x86/kernel/static_call.c

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index b5286ad2a982..a2a10e0ce248 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -189,6 +189,7 @@ config X86
 	select HAVE_FUNCTION_ARG_ACCESS_API
 	select HAVE_STACKPROTECTOR		if CC_HAS_SANE_STACKPROTECTOR
 	select HAVE_STACK_VALIDATION		if X86_64
+	select HAVE_STATIC_CALL_OUTLINE
 	select HAVE_RSEQ
 	select HAVE_SYSCALL_TRACEPOINTS
 	select HAVE_UNSTABLE_SCHED_CLOCK
diff --git a/arch/x86/include/asm/static_call.h b/arch/x86/include/asm/static_call.h
new file mode 100644
index 000000000000..6e9ad5969ec2
--- /dev/null
+++ b/arch/x86/include/asm/static_call.h
@@ -0,0 +1,28 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _ASM_STATIC_CALL_H
+#define _ASM_STATIC_CALL_H
+
+/*
+ * Manually construct a 5-byte direct JMP to prevent the assembler from
+ * optimizing it into a 2-byte JMP.
+ */
+#define __ARCH_STATIC_CALL_JMP_LABEL(key) ".L" __stringify(key ## _after_jmp)
+#define __ARCH_STATIC_CALL_TRAMP_JMP(key, func)				\
+	".byte 0xe9						\n"	\
+	".long " #func " - " __ARCH_STATIC_CALL_JMP_LABEL(key) "\n"	\
+	__ARCH_STATIC_CALL_JMP_LABEL(key) ":"
+
+/*
+ * This is a permanent trampoline which does a direct jump to the function.
+ * The direct jump get patched by static_call_update().
+ */
+#define ARCH_DEFINE_STATIC_CALL_TRAMP(key, func)			\
+	asm(".pushsection .text, \"ax\"				\n"	\
+	    ".align 4						\n"	\
+	    ".globl " STATIC_CALL_TRAMP_STR(key) "		\n"	\
+	    ".type " STATIC_CALL_TRAMP_STR(key) ", @function	\n"	\
+	    STATIC_CALL_TRAMP_STR(key) ":			\n"	\
+	    __ARCH_STATIC_CALL_TRAMP_JMP(key, func) "           \n"	\
+	    ".popsection					\n")
+
+#endif /* _ASM_STATIC_CALL_H */
diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
index 8824d01c0c35..82acc8a28429 100644
--- a/arch/x86/kernel/Makefile
+++ b/arch/x86/kernel/Makefile
@@ -62,6 +62,7 @@ obj-y			+= tsc.o tsc_msr.o io_delay.o rtc.o
 obj-y			+= pci-iommu_table.o
 obj-y			+= resource.o
 obj-y			+= irqflags.o
+obj-y			+= static_call.o
 
 obj-y				+= process.o
 obj-y				+= fpu/
diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
new file mode 100644
index 000000000000..8026d176f25c
--- /dev/null
+++ b/arch/x86/kernel/static_call.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/static_call.h>
+#include <linux/memory.h>
+#include <linux/bug.h>
+#include <asm/text-patching.h>
+#include <asm/nospec-branch.h>
+
+#define CALL_INSN_SIZE 5
+
+void static_call_bp_handler(void);
+void *bp_handler_dest;
+
+asm(".pushsection .text, \"ax\"						\n"
+    ".globl static_call_bp_handler					\n"
+    ".type static_call_bp_handler, @function				\n"
+    "static_call_bp_handler:						\n"
+    "ANNOTATE_RETPOLINE_SAFE						\n"
+    "jmp *bp_handler_dest						\n"
+    ".popsection							\n");
+
+void arch_static_call_transform(void *site, void *tramp, void *func)
+{
+	s32 dest_relative;
+	unsigned long insn;
+	unsigned char insn_opcode;
+	unsigned char opcodes[CALL_INSN_SIZE];
+
+	insn = (unsigned long)tramp;
+
+	mutex_lock(&text_mutex);
+
+	insn_opcode = *(unsigned char *)insn;
+	if (insn_opcode != 0xe8 && insn_opcode != 0xe9) {
+		WARN_ONCE(1, "unexpected static call insn opcode 0x%x at %pS",
+			  insn_opcode, (void *)insn);
+		goto done;
+	}
+
+	dest_relative = (long)(func) - (long)(insn + CALL_INSN_SIZE);
+
+	opcodes[0] = insn_opcode;
+	memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
+
+	/* Set up the variable for the breakpoint handler: */
+	bp_handler_dest = func;
+
+	/* Patch the call site: */
+	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
+		     static_call_bp_handler);
+
+done:
+	mutex_unlock(&text_mutex);
+}
+EXPORT_SYMBOL_GPL(arch_static_call_transform);
diff --git a/include/linux/static_call.h b/include/linux/static_call.h
index c8d0da1ef6b2..651f4d784377 100644
--- a/include/linux/static_call.h
+++ b/include/linux/static_call.h
@@ -149,7 +149,7 @@ struct static_call_key {
 		.func = _func,						\
 		.tramp = STATIC_CALL_TRAMP(key),			\
 	};								\
-	ARCH_DEFINE_STATIC_CALL_TRAMP(key, func)
+	ARCH_DEFINE_STATIC_CALL_TRAMP(key, _func)
 
 #define static_call(key, args...) STATIC_CALL_TRAMP(key)(args)
 
-- 
2.17.2


^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 13:54 [PATCH v2 0/4] Static calls Josh Poimboeuf
                   ` (2 preceding siblings ...)
  2018-11-26 13:54 ` [PATCH v2 3/4] x86/static_call: Add out-of-line static call implementation Josh Poimboeuf
@ 2018-11-26 13:55 ` Josh Poimboeuf
  2018-11-26 16:02   ` Peter Zijlstra
  2018-11-26 16:08   ` Peter Zijlstra
  2018-11-26 14:01 ` [PATCH v2 0/4] Static calls Josh Poimboeuf
                   ` (4 subsequent siblings)
  8 siblings, 2 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 13:55 UTC (permalink / raw)
  To: x86
  Cc: linux-kernel, Ard Biesheuvel, Andy Lutomirski, Steven Rostedt,
	Peter Zijlstra, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

Add the inline static call implementation for x86-64.  For each key, a
temporary trampoline is created, named __static_call_tramp_<key>.  The
trampoline has an indirect jump to the destination function.

Objtool uses the trampoline naming convention to detect all the call
sites.  It then annotates those call sites in the .static_call_sites
section.

During boot (and module init), the call sites are patched to call
directly into the destination function.  The temporary trampoline is
then no longer used.

Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>
---
 arch/x86/Kconfig                              |   5 +-
 arch/x86/include/asm/static_call.h            |  28 +++-
 arch/x86/kernel/asm-offsets.c                 |   6 +
 arch/x86/kernel/static_call.c                 |  30 ++++-
 include/linux/static_call.h                   |   2 +-
 tools/objtool/Makefile                        |   3 +-
 tools/objtool/check.c                         | 126 +++++++++++++++++-
 tools/objtool/check.h                         |   2 +
 tools/objtool/elf.h                           |   1 +
 .../objtool/include/linux/static_call_types.h |  19 +++
 tools/objtool/sync-check.sh                   |   1 +
 11 files changed, 213 insertions(+), 10 deletions(-)
 create mode 100644 tools/objtool/include/linux/static_call_types.h

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index a2a10e0ce248..e099ea87ea70 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -189,7 +189,8 @@ config X86
 	select HAVE_FUNCTION_ARG_ACCESS_API
 	select HAVE_STACKPROTECTOR		if CC_HAS_SANE_STACKPROTECTOR
 	select HAVE_STACK_VALIDATION		if X86_64
-	select HAVE_STATIC_CALL_OUTLINE
+	select HAVE_STATIC_CALL_INLINE		if HAVE_STACK_VALIDATION
+	select HAVE_STATIC_CALL_OUTLINE		if !HAVE_STACK_VALIDATION
 	select HAVE_RSEQ
 	select HAVE_SYSCALL_TRACEPOINTS
 	select HAVE_UNSTABLE_SCHED_CLOCK
@@ -203,6 +204,7 @@ config X86
 	select RTC_MC146818_LIB
 	select SPARSE_IRQ
 	select SRCU
+	select STACK_VALIDATION			if HAVE_STACK_VALIDATION && (HAVE_STATIC_CALL_INLINE || RETPOLINE)
 	select SYSCTL_EXCEPTION_TRACE
 	select THREAD_INFO_IN_TASK
 	select USER_STACKTRACE_SUPPORT
@@ -438,7 +440,6 @@ config GOLDFISH
 config RETPOLINE
 	bool "Avoid speculative indirect branches in kernel"
 	default y
-	select STACK_VALIDATION if HAVE_STACK_VALIDATION
 	help
 	  Compile kernel with the retpoline compiler options to guard against
 	  kernel-to-user data leaks by avoiding speculative indirect
diff --git a/arch/x86/include/asm/static_call.h b/arch/x86/include/asm/static_call.h
index 6e9ad5969ec2..27bd7da16150 100644
--- a/arch/x86/include/asm/static_call.h
+++ b/arch/x86/include/asm/static_call.h
@@ -2,6 +2,20 @@
 #ifndef _ASM_STATIC_CALL_H
 #define _ASM_STATIC_CALL_H
 
+#include <asm/asm-offsets.h>
+
+#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
+
+/*
+ * This trampoline is only used during boot / module init, so it's safe to use
+ * the indirect branch without a retpoline.
+ */
+#define __ARCH_STATIC_CALL_TRAMP_JMP(key, func)				\
+	ANNOTATE_RETPOLINE_SAFE						\
+	"jmpq *" __stringify(key) "+" __stringify(SC_KEY_func) "(%rip) \n"
+
+#else /* !CONFIG_HAVE_STATIC_CALL_INLINE */
+
 /*
  * Manually construct a 5-byte direct JMP to prevent the assembler from
  * optimizing it into a 2-byte JMP.
@@ -12,9 +26,19 @@
 	".long " #func " - " __ARCH_STATIC_CALL_JMP_LABEL(key) "\n"	\
 	__ARCH_STATIC_CALL_JMP_LABEL(key) ":"
 
+#endif /* !CONFIG_HAVE_STATIC_CALL_INLINE */
+
 /*
- * This is a permanent trampoline which does a direct jump to the function.
- * The direct jump get patched by static_call_update().
+ * For CONFIG_HAVE_STATIC_CALL_INLINE, this is a temporary trampoline which
+ * uses the current value of the key->func pointer to do an indirect jump to
+ * the function.  This trampoline is only used during boot, before the call
+ * sites get patched by static_call_update().  The name of this trampoline has
+ * a magical aspect: objtool uses it to find static call sites so it can create
+ * the .static_call_sites section.
+ *
+ * For CONFIG_HAVE_STATIC_CALL_OUTLINE, this is a permanent trampoline which
+ * does a direct jump to the function.  The direct jump gets patched by
+ * static_call_update().
  */
 #define ARCH_DEFINE_STATIC_CALL_TRAMP(key, func)			\
 	asm(".pushsection .text, \"ax\"				\n"	\
diff --git a/arch/x86/kernel/asm-offsets.c b/arch/x86/kernel/asm-offsets.c
index 72adf6c335dc..da8fd220e4f2 100644
--- a/arch/x86/kernel/asm-offsets.c
+++ b/arch/x86/kernel/asm-offsets.c
@@ -12,6 +12,7 @@
 #include <linux/hardirq.h>
 #include <linux/suspend.h>
 #include <linux/kbuild.h>
+#include <linux/static_call.h>
 #include <asm/processor.h>
 #include <asm/thread_info.h>
 #include <asm/sigframe.h>
@@ -104,4 +105,9 @@ void common(void) {
 	OFFSET(TSS_sp0, tss_struct, x86_tss.sp0);
 	OFFSET(TSS_sp1, tss_struct, x86_tss.sp1);
 	OFFSET(TSS_sp2, tss_struct, x86_tss.sp2);
+
+#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
+	BLANK();
+	OFFSET(SC_KEY_func, static_call_key, func);
+#endif
 }
diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
index 8026d176f25c..d3869295b88d 100644
--- a/arch/x86/kernel/static_call.c
+++ b/arch/x86/kernel/static_call.c
@@ -9,13 +9,21 @@
 
 void static_call_bp_handler(void);
 void *bp_handler_dest;
+void *bp_handler_continue;
 
 asm(".pushsection .text, \"ax\"						\n"
     ".globl static_call_bp_handler					\n"
     ".type static_call_bp_handler, @function				\n"
     "static_call_bp_handler:						\n"
-    "ANNOTATE_RETPOLINE_SAFE						\n"
+#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
+    ANNOTATE_RETPOLINE_SAFE
+    "call *bp_handler_dest						\n"
+    ANNOTATE_RETPOLINE_SAFE
+    "jmp *bp_handler_continue						\n"
+#else /* !CONFIG_HAVE_STATIC_CALL_INLINE */
+    ANNOTATE_RETPOLINE_SAFE
     "jmp *bp_handler_dest						\n"
+#endif
     ".popsection							\n");
 
 void arch_static_call_transform(void *site, void *tramp, void *func)
@@ -25,7 +33,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
 	unsigned char insn_opcode;
 	unsigned char opcodes[CALL_INSN_SIZE];
 
-	insn = (unsigned long)tramp;
+	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
+		insn = (unsigned long)site;
+	else
+		insn = (unsigned long)tramp;
 
 	mutex_lock(&text_mutex);
 
@@ -41,8 +52,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
 	opcodes[0] = insn_opcode;
 	memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
 
-	/* Set up the variable for the breakpoint handler: */
+	/* Set up the variables for the breakpoint handler: */
 	bp_handler_dest = func;
+	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
+		bp_handler_continue = (void *)(insn + CALL_INSN_SIZE);
 
 	/* Patch the call site: */
 	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
@@ -52,3 +65,14 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
 	mutex_unlock(&text_mutex);
 }
 EXPORT_SYMBOL_GPL(arch_static_call_transform);
+
+#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
+void arch_static_call_defuse_tramp(void *site, void *tramp)
+{
+	unsigned short opcode = INSN_UD2;
+
+	mutex_lock(&text_mutex);
+	text_poke((void *)tramp, &opcode, 2);
+	mutex_unlock(&text_mutex);
+}
+#endif
diff --git a/include/linux/static_call.h b/include/linux/static_call.h
index 651f4d784377..6daff586c97d 100644
--- a/include/linux/static_call.h
+++ b/include/linux/static_call.h
@@ -70,7 +70,7 @@
 #include <linux/cpu.h>
 #include <linux/static_call_types.h>
 
-#ifdef CONFIG_HAVE_STATIC_CALL
+#if defined(CONFIG_HAVE_STATIC_CALL) && !defined(COMPILE_OFFSETS)
 #include <asm/static_call.h>
 extern void arch_static_call_transform(void *site, void *tramp, void *func);
 #endif
diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile
index c9d038f91af6..fb1afa34f10d 100644
--- a/tools/objtool/Makefile
+++ b/tools/objtool/Makefile
@@ -29,7 +29,8 @@ all: $(OBJTOOL)
 
 INCLUDES := -I$(srctree)/tools/include \
 	    -I$(srctree)/tools/arch/$(HOSTARCH)/include/uapi \
-	    -I$(srctree)/tools/objtool/arch/$(ARCH)/include
+	    -I$(srctree)/tools/objtool/arch/$(ARCH)/include \
+	    -I$(srctree)/tools/objtool/include
 WARNINGS := $(EXTRA_WARNINGS) -Wno-switch-default -Wno-switch-enum -Wno-packed
 CFLAGS   += -Werror $(WARNINGS) $(KBUILD_HOSTCFLAGS) -g $(INCLUDES)
 LDFLAGS  += -lelf $(LIBSUBCMD) $(KBUILD_HOSTLDFLAGS)
diff --git a/tools/objtool/check.c b/tools/objtool/check.c
index 0414a0d52262..ea1ff9ea2d78 100644
--- a/tools/objtool/check.c
+++ b/tools/objtool/check.c
@@ -27,6 +27,7 @@
 
 #include <linux/hashtable.h>
 #include <linux/kernel.h>
+#include <linux/static_call_types.h>
 
 struct alternative {
 	struct list_head list;
@@ -165,6 +166,7 @@ static int __dead_end_function(struct objtool_file *file, struct symbol *func,
 		"fortify_panic",
 		"usercopy_abort",
 		"machine_real_restart",
+		"rewind_stack_do_exit",
 	};
 
 	if (func->bind == STB_WEAK)
@@ -525,6 +527,10 @@ static int add_jump_destinations(struct objtool_file *file)
 		} else {
 			/* sibling call */
 			insn->jump_dest = 0;
+			if (rela->sym->static_call_tramp) {
+				list_add_tail(&insn->static_call_node,
+					      &file->static_call_list);
+			}
 			continue;
 		}
 
@@ -1202,6 +1208,24 @@ static int read_retpoline_hints(struct objtool_file *file)
 	return 0;
 }
 
+static int read_static_call_tramps(struct objtool_file *file)
+{
+	struct section *sec;
+	struct symbol *func;
+
+	for_each_sec(file, sec) {
+		list_for_each_entry(func, &sec->symbol_list, list) {
+			if (func->bind == STB_GLOBAL &&
+			    !strncmp(func->name, STATIC_CALL_TRAMP_PREFIX_STR,
+				     strlen(STATIC_CALL_TRAMP_PREFIX_STR)))
+				func->static_call_tramp = true;
+		}
+
+	}
+
+	return 0;
+}
+
 static void mark_rodata(struct objtool_file *file)
 {
 	struct section *sec;
@@ -1267,6 +1291,10 @@ static int decode_sections(struct objtool_file *file)
 	if (ret)
 		return ret;
 
+	ret = read_static_call_tramps(file);
+	if (ret)
+		return ret;
+
 	return 0;
 }
 
@@ -1920,6 +1948,11 @@ static int validate_branch(struct objtool_file *file, struct instruction *first,
 			if (is_fentry_call(insn))
 				break;
 
+			if (insn->call_dest->static_call_tramp) {
+				list_add_tail(&insn->static_call_node,
+					      &file->static_call_list);
+			}
+
 			ret = dead_end_function(file, insn->call_dest);
 			if (ret == 1)
 				return 0;
@@ -2167,6 +2200,89 @@ static int validate_reachable_instructions(struct objtool_file *file)
 	return 0;
 }
 
+static int create_static_call_sections(struct objtool_file *file)
+{
+	struct section *sec, *rela_sec;
+	struct rela *rela;
+	struct static_call_site *site;
+	struct instruction *insn;
+	char *key_name;
+	struct symbol *key_sym;
+	int idx;
+
+	sec = find_section_by_name(file->elf, ".static_call_sites");
+	if (sec) {
+		WARN("file already has .static_call_sites section, skipping");
+		return 0;
+	}
+
+	if (list_empty(&file->static_call_list))
+		return 0;
+
+	idx = 0;
+	list_for_each_entry(insn, &file->static_call_list, static_call_node)
+		idx++;
+
+	sec = elf_create_section(file->elf, ".static_call_sites",
+				 sizeof(struct static_call_site), idx);
+	if (!sec)
+		return -1;
+
+	rela_sec = elf_create_rela_section(file->elf, sec);
+	if (!rela_sec)
+		return -1;
+
+	idx = 0;
+	list_for_each_entry(insn, &file->static_call_list, static_call_node) {
+
+		site = (struct static_call_site *)sec->data->d_buf + idx;
+		memset(site, 0, sizeof(struct static_call_site));
+
+		/* populate rela for 'addr' */
+		rela = malloc(sizeof(*rela));
+		if (!rela) {
+			perror("malloc");
+			return -1;
+		}
+		memset(rela, 0, sizeof(*rela));
+		rela->sym = insn->sec->sym;
+		rela->addend = insn->offset;
+		rela->type = R_X86_64_PC32;
+		rela->offset = idx * sizeof(struct static_call_site);
+		list_add_tail(&rela->list, &rela_sec->rela_list);
+		hash_add(rela_sec->rela_hash, &rela->hash, rela->offset);
+
+		/* find key symbol */
+		key_name = insn->call_dest->name + strlen(STATIC_CALL_TRAMP_PREFIX_STR);
+		key_sym = find_symbol_by_name(file->elf, key_name);
+		if (!key_sym) {
+			WARN("can't find static call key symbol: %s", key_name);
+			return -1;
+		}
+
+		/* populate rela for 'key' */
+		rela = malloc(sizeof(*rela));
+		if (!rela) {
+			perror("malloc");
+			return -1;
+		}
+		memset(rela, 0, sizeof(*rela));
+		rela->sym = key_sym;
+		rela->addend = 0;
+		rela->type = R_X86_64_PC32;
+		rela->offset = idx * sizeof(struct static_call_site) + 4;
+		list_add_tail(&rela->list, &rela_sec->rela_list);
+		hash_add(rela_sec->rela_hash, &rela->hash, rela->offset);
+
+		idx++;
+	}
+
+	if (elf_rebuild_rela_section(rela_sec))
+		return -1;
+
+	return 0;
+}
+
 static void cleanup(struct objtool_file *file)
 {
 	struct instruction *insn, *tmpinsn;
@@ -2191,12 +2307,13 @@ int check(const char *_objname, bool orc)
 
 	objname = _objname;
 
-	file.elf = elf_open(objname, orc ? O_RDWR : O_RDONLY);
+	file.elf = elf_open(objname, O_RDWR);
 	if (!file.elf)
 		return 1;
 
 	INIT_LIST_HEAD(&file.insn_list);
 	hash_init(file.insn_hash);
+	INIT_LIST_HEAD(&file.static_call_list);
 	file.whitelist = find_section_by_name(file.elf, ".discard.func_stack_frame_non_standard");
 	file.c_file = find_section_by_name(file.elf, ".comment");
 	file.ignore_unreachables = no_unreachable;
@@ -2236,6 +2353,11 @@ int check(const char *_objname, bool orc)
 		warnings += ret;
 	}
 
+	ret = create_static_call_sections(&file);
+	if (ret < 0)
+		goto out;
+	warnings += ret;
+
 	if (orc) {
 		ret = create_orc(&file);
 		if (ret < 0)
@@ -2244,7 +2366,9 @@ int check(const char *_objname, bool orc)
 		ret = create_orc_sections(&file);
 		if (ret < 0)
 			goto out;
+	}
 
+	if (orc || !list_empty(&file.static_call_list)) {
 		ret = elf_write(file.elf);
 		if (ret < 0)
 			goto out;
diff --git a/tools/objtool/check.h b/tools/objtool/check.h
index e6e8a655b556..56b8b7fb1bd1 100644
--- a/tools/objtool/check.h
+++ b/tools/objtool/check.h
@@ -39,6 +39,7 @@ struct insn_state {
 struct instruction {
 	struct list_head list;
 	struct hlist_node hash;
+	struct list_head static_call_node;
 	struct section *sec;
 	unsigned long offset;
 	unsigned int len;
@@ -60,6 +61,7 @@ struct objtool_file {
 	struct elf *elf;
 	struct list_head insn_list;
 	DECLARE_HASHTABLE(insn_hash, 16);
+	struct list_head static_call_list;
 	struct section *whitelist;
 	bool ignore_unreachables, c_file, hints, rodata;
 };
diff --git a/tools/objtool/elf.h b/tools/objtool/elf.h
index bc97ed86b9cd..3cf44d7cc3ac 100644
--- a/tools/objtool/elf.h
+++ b/tools/objtool/elf.h
@@ -62,6 +62,7 @@ struct symbol {
 	unsigned long offset;
 	unsigned int len;
 	struct symbol *pfunc, *cfunc;
+	bool static_call_tramp;
 };
 
 struct rela {
diff --git a/tools/objtool/include/linux/static_call_types.h b/tools/objtool/include/linux/static_call_types.h
new file mode 100644
index 000000000000..6859b208de6e
--- /dev/null
+++ b/tools/objtool/include/linux/static_call_types.h
@@ -0,0 +1,19 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _STATIC_CALL_TYPES_H
+#define _STATIC_CALL_TYPES_H
+
+#include <linux/stringify.h>
+
+#define STATIC_CALL_TRAMP_PREFIX ____static_call_tramp_
+#define STATIC_CALL_TRAMP_PREFIX_STR __stringify(STATIC_CALL_TRAMP_PREFIX)
+
+#define STATIC_CALL_TRAMP(key) __PASTE(STATIC_CALL_TRAMP_PREFIX, key)
+#define STATIC_CALL_TRAMP_STR(key) __stringify(STATIC_CALL_TRAMP(key))
+
+/* The static call site table is created by objtool. */
+struct static_call_site {
+	s32 addr;
+	s32 key;
+};
+
+#endif /* _STATIC_CALL_TYPES_H */
diff --git a/tools/objtool/sync-check.sh b/tools/objtool/sync-check.sh
index 1470e74e9d66..e1a204bf3556 100755
--- a/tools/objtool/sync-check.sh
+++ b/tools/objtool/sync-check.sh
@@ -10,6 +10,7 @@ arch/x86/include/asm/insn.h
 arch/x86/include/asm/inat.h
 arch/x86/include/asm/inat_types.h
 arch/x86/include/asm/orc_types.h
+include/linux/static_call_types.h
 '
 
 check()
-- 
2.17.2


^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-11-26 13:54 [PATCH v2 0/4] Static calls Josh Poimboeuf
                   ` (3 preceding siblings ...)
  2018-11-26 13:55 ` [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64 Josh Poimboeuf
@ 2018-11-26 14:01 ` Josh Poimboeuf
  2018-11-26 20:54 ` Steven Rostedt
                   ` (3 subsequent siblings)
  8 siblings, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 14:01 UTC (permalink / raw)
  To: x86, Steven Rostedt
  Cc: linux-kernel, Ard Biesheuvel, Andy Lutomirski, Peter Zijlstra,
	Ingo Molnar, Thomas Gleixner, Linus Torvalds, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov,
	Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 07:54:56AM -0600, Josh Poimboeuf wrote:
> v2:
> - fix STATIC_CALL_TRAMP() macro by using __PASTE() [Ard]
> - rename optimized/unoptimized -> inline/out-of-line [Ard]
> - tweak arch interfaces for PLT and add key->tramp field [Ard]
> - rename 'poison' to 'defuse' and do it after all sites have been patched [Ard]
> - fix .init handling [Ard, Steven]
> - add CONFIG_HAVE_STATIC_CALL [Steven]
> - make interfaces more consistent across configs to allow tracepoints to
>   use them [Steven]
> - move __ADDRESSABLE() to static_call() macro [Steven]
> - prevent 2-byte jumps [Steven]
> - add offset to asm-offsets.c instead of hard coding key->func offset
> - add kernel_text_address() sanity check
> - make __ADDRESSABLE() symbols truly unique
> 
> TODO:
> - port Ard's arm64 patches to the new arch interfaces
> - tracepoint performance testing

Below is the patch Steve gave me for converting tracepoints to use
static calls.

Steve, if you want me to do the performance testing, send me the test
details and I can give it a try this week.



diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h
index 49ba9cde7e4b..ae16672bea61 100644
--- a/include/linux/tracepoint-defs.h
+++ b/include/linux/tracepoint-defs.h
@@ -11,6 +11,8 @@
 #include <linux/atomic.h>
 #include <linux/static_key.h>
 
+struct static_call_key;
+
 struct trace_print_flags {
 	unsigned long		mask;
 	const char		*name;
@@ -30,6 +32,8 @@ struct tracepoint_func {
 struct tracepoint {
 	const char *name;		/* Tracepoint name */
 	struct static_key key;
+	struct static_call_key *static_call_key;
+	void *iterator;
 	int (*regfunc)(void);
 	void (*unregfunc)(void);
 	struct tracepoint_func __rcu *funcs;
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 538ba1a58f5b..bddaf6043027 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -21,6 +21,7 @@
 #include <linux/cpumask.h>
 #include <linux/rcupdate.h>
 #include <linux/tracepoint-defs.h>
+#include <linux/static_call.h>
 
 struct module;
 struct tracepoint;
@@ -94,7 +95,9 @@ extern int syscall_regfunc(void);
 extern void syscall_unregfunc(void);
 #endif /* CONFIG_HAVE_SYSCALL_TRACEPOINTS */
 
+#ifndef PARAMS
 #define PARAMS(args...) args
+#endif
 
 #define TRACE_DEFINE_ENUM(x)
 #define TRACE_DEFINE_SIZEOF(x)
@@ -161,12 +164,11 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
  * as "(void *, void)". The DECLARE_TRACE_NOARGS() will pass in just
  * "void *data", where as the DECLARE_TRACE() will pass in "void *data, proto".
  */
-#define __DO_TRACE(tp, proto, args, cond, rcuidle)			\
+#define __DO_TRACE(name, proto, args, cond, rcuidle)			\
 	do {								\
 		struct tracepoint_func *it_func_ptr;			\
-		void *it_func;						\
-		void *__data;						\
 		int __maybe_unused idx = 0;				\
+		void *__data;						\
 									\
 		if (!(cond))						\
 			return;						\
@@ -186,14 +188,11 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
 			rcu_irq_enter_irqson();				\
 		}							\
 									\
-		it_func_ptr = rcu_dereference_raw((tp)->funcs);		\
-									\
+		it_func_ptr =						\
+			rcu_dereference_raw((&__tracepoint_##name)->funcs); \
 		if (it_func_ptr) {					\
-			do {						\
-				it_func = (it_func_ptr)->func;		\
-				__data = (it_func_ptr)->data;		\
-				((void(*)(proto))(it_func))(args);	\
-			} while ((++it_func_ptr)->func);		\
+			__data = (it_func_ptr)->data;			\
+			static_call(__tp_func_##name, args);		\
 		}							\
 									\
 		if (rcuidle) {						\
@@ -209,7 +208,7 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
 	static inline void trace_##name##_rcuidle(proto)		\
 	{								\
 		if (static_key_false(&__tracepoint_##name.key))		\
-			__DO_TRACE(&__tracepoint_##name,		\
+			__DO_TRACE(name,				\
 				TP_PROTO(data_proto),			\
 				TP_ARGS(data_args),			\
 				TP_CONDITION(cond), 1);			\
@@ -231,11 +230,13 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
  * poking RCU a bit.
  */
 #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
+	extern int __tracepoint_iter_##name(data_proto);		\
+	DECLARE_STATIC_CALL(__tp_func_##name, __tracepoint_iter_##name); \
 	extern struct tracepoint __tracepoint_##name;			\
 	static inline void trace_##name(proto)				\
 	{								\
 		if (static_key_false(&__tracepoint_##name.key))		\
-			__DO_TRACE(&__tracepoint_##name,		\
+			__DO_TRACE(name,				\
 				TP_PROTO(data_proto),			\
 				TP_ARGS(data_args),			\
 				TP_CONDITION(cond), 0);			\
@@ -281,21 +282,43 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
  * structures, so we create an array of pointers that will be used for iteration
  * on the tracepoints.
  */
-#define DEFINE_TRACE_FN(name, reg, unreg)				 \
-	static const char __tpstrtab_##name[]				 \
-	__attribute__((section("__tracepoints_strings"))) = #name;	 \
-	struct tracepoint __tracepoint_##name				 \
-	__attribute__((section("__tracepoints"), used)) =		 \
-		{ __tpstrtab_##name, STATIC_KEY_INIT_FALSE, reg, unreg, NULL };\
-	__TRACEPOINT_ENTRY(name);
+#define DEFINE_TRACE_FN(name, reg, unreg, proto, args)			\
+	static const char __tpstrtab_##name[]				\
+	__attribute__((section("__tracepoints_strings"))) = #name;	\
+	extern struct static_call_key __tp_func_##name;			\
+	int __tracepoint_iter_##name(void *__data, proto);		\
+	struct tracepoint __tracepoint_##name				\
+	__attribute__((section("__tracepoints"), used)) =		\
+		{ __tpstrtab_##name, STATIC_KEY_INIT_FALSE,		\
+		  &__tp_func_##name, __tracepoint_iter_##name,		\
+		  reg, unreg, NULL };					\
+	__TRACEPOINT_ENTRY(name);					\
+	int __tracepoint_iter_##name(void *__data, proto)		\
+	{								\
+		struct tracepoint_func *it_func_ptr;			\
+		void *it_func;						\
+									\
+		it_func_ptr =						\
+			rcu_dereference_raw((&__tracepoint_##name)->funcs); \
+		do {							\
+			it_func = (it_func_ptr)->func;			\
+			__data = (it_func_ptr)->data;			\
+			((void(*)(void *, proto))(it_func))(__data, args); \
+		} while ((++it_func_ptr)->func);			\
+		return 0;						\
+	}								\
+	DEFINE_STATIC_CALL(__tp_func_##name, __tracepoint_iter_##name);
 
-#define DEFINE_TRACE(name)						\
-	DEFINE_TRACE_FN(name, NULL, NULL);
+#define DEFINE_TRACE(name, proto, args)		\
+	DEFINE_TRACE_FN(name, NULL, NULL, PARAMS(proto), PARAMS(args));
 
 #define EXPORT_TRACEPOINT_SYMBOL_GPL(name)				\
-	EXPORT_SYMBOL_GPL(__tracepoint_##name)
+	EXPORT_SYMBOL_GPL(__tracepoint_##name);				\
+	EXPORT_STATIC_CALL_GPL(__tp_func_##name)
 #define EXPORT_TRACEPOINT_SYMBOL(name)					\
-	EXPORT_SYMBOL(__tracepoint_##name)
+	EXPORT_SYMBOL(__tracepoint_##name);				\
+	EXPORT_STATIC_CALL(__tp_func_##name)
+
 
 #else /* !TRACEPOINTS_ENABLED */
 #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
@@ -324,8 +347,8 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
 		return false;						\
 	}
 
-#define DEFINE_TRACE_FN(name, reg, unreg)
-#define DEFINE_TRACE(name)
+#define DEFINE_TRACE_FN(name, reg, unreg, proto, args)
+#define DEFINE_TRACE(name, proto, args)
 #define EXPORT_TRACEPOINT_SYMBOL_GPL(name)
 #define EXPORT_TRACEPOINT_SYMBOL(name)
 
diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h
index cb30c5532144..c19aea44efb2 100644
--- a/include/trace/define_trace.h
+++ b/include/trace/define_trace.h
@@ -25,7 +25,7 @@
 
 #undef TRACE_EVENT
 #define TRACE_EVENT(name, proto, args, tstruct, assign, print)	\
-	DEFINE_TRACE(name)
+	DEFINE_TRACE(name, PARAMS(proto), PARAMS(args))
 
 #undef TRACE_EVENT_CONDITION
 #define TRACE_EVENT_CONDITION(name, proto, args, cond, tstruct, assign, print) \
@@ -39,24 +39,24 @@
 #undef TRACE_EVENT_FN
 #define TRACE_EVENT_FN(name, proto, args, tstruct,		\
 		assign, print, reg, unreg)			\
-	DEFINE_TRACE_FN(name, reg, unreg)
+	DEFINE_TRACE_FN(name, reg, unreg, PARAMS(proto), PARAMS(args))
 
 #undef TRACE_EVENT_FN_COND
 #define TRACE_EVENT_FN_COND(name, proto, args, cond, tstruct,		\
 		assign, print, reg, unreg)			\
-	DEFINE_TRACE_FN(name, reg, unreg)
+	DEFINE_TRACE_FN(name, reg, unreg, PARAMS(proto), PARAMS(args))
 
 #undef DEFINE_EVENT
 #define DEFINE_EVENT(template, name, proto, args) \
-	DEFINE_TRACE(name)
+	DEFINE_TRACE(name, PARAMS(proto), PARAMS(args))
 
 #undef DEFINE_EVENT_FN
 #define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg) \
-	DEFINE_TRACE_FN(name, reg, unreg)
+	DEFINE_TRACE_FN(name, reg, unreg, PARAMS(proto), PARAMS(args))
 
 #undef DEFINE_EVENT_PRINT
 #define DEFINE_EVENT_PRINT(template, name, proto, args, print)	\
-	DEFINE_TRACE(name)
+	DEFINE_TRACE(name, PARAMS(proto), PARAMS(args))
 
 #undef DEFINE_EVENT_CONDITION
 #define DEFINE_EVENT_CONDITION(template, name, proto, args, cond) \
@@ -64,7 +64,7 @@
 
 #undef DECLARE_TRACE
 #define DECLARE_TRACE(name, proto, args)	\
-	DEFINE_TRACE(name)
+	DEFINE_TRACE(name, PARAMS(proto), PARAMS(args))
 
 #undef TRACE_INCLUDE
 #undef __TRACE_INCLUDE
diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index a3be42304485..55ccf794f4d3 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -140,7 +140,7 @@ static void debug_print_probes(struct tracepoint_func *funcs)
 
 static struct tracepoint_func *
 func_add(struct tracepoint_func **funcs, struct tracepoint_func *tp_func,
-	 int prio)
+	 int prio, int *tot_probes)
 {
 	struct tracepoint_func *old, *new;
 	int nr_probes = 0;
@@ -183,11 +183,12 @@ func_add(struct tracepoint_func **funcs, struct tracepoint_func *tp_func,
 	new[nr_probes + 1].func = NULL;
 	*funcs = new;
 	debug_print_probes(*funcs);
+	*tot_probes = nr_probes + 1;
 	return old;
 }
 
 static void *func_remove(struct tracepoint_func **funcs,
-		struct tracepoint_func *tp_func)
+		struct tracepoint_func *tp_func, int *left)
 {
 	int nr_probes = 0, nr_del = 0, i;
 	struct tracepoint_func *old, *new;
@@ -241,6 +242,7 @@ static int tracepoint_add_func(struct tracepoint *tp,
 			       struct tracepoint_func *func, int prio)
 {
 	struct tracepoint_func *old, *tp_funcs;
+	int probes = 0;
 	int ret;
 
 	if (tp->regfunc && !static_key_enabled(&tp->key)) {
@@ -251,7 +253,7 @@ static int tracepoint_add_func(struct tracepoint *tp,
 
 	tp_funcs = rcu_dereference_protected(tp->funcs,
 			lockdep_is_held(&tracepoints_mutex));
-	old = func_add(&tp_funcs, func, prio);
+	old = func_add(&tp_funcs, func, prio, &probes);
 	if (IS_ERR(old)) {
 		WARN_ON_ONCE(PTR_ERR(old) != -ENOMEM);
 		return PTR_ERR(old);
@@ -266,6 +268,12 @@ static int tracepoint_add_func(struct tracepoint *tp,
 	rcu_assign_pointer(tp->funcs, tp_funcs);
 	if (!static_key_enabled(&tp->key))
 		static_key_slow_inc(&tp->key);
+
+	if (probes == 1)
+		__static_call_update(tp->static_call_key, tp_funcs->func);
+	else
+		__static_call_update(tp->static_call_key, tp->iterator);
+
 	release_probes(old);
 	return 0;
 }
@@ -280,10 +288,11 @@ static int tracepoint_remove_func(struct tracepoint *tp,
 		struct tracepoint_func *func)
 {
 	struct tracepoint_func *old, *tp_funcs;
+	int probes_left = 0;
 
 	tp_funcs = rcu_dereference_protected(tp->funcs,
 			lockdep_is_held(&tracepoints_mutex));
-	old = func_remove(&tp_funcs, func);
+	old = func_remove(&tp_funcs, func, &probes_left);
 	if (IS_ERR(old)) {
 		WARN_ON_ONCE(PTR_ERR(old) != -ENOMEM);
 		return PTR_ERR(old);
@@ -297,6 +306,12 @@ static int tracepoint_remove_func(struct tracepoint *tp,
 		if (static_key_enabled(&tp->key))
 			static_key_slow_dec(&tp->key);
 	}
+
+	if (probes_left == 1)
+		__static_call_update(tp->static_call_key, tp_funcs->func);
+	else
+		__static_call_update(tp->static_call_key, tp->iterator);
+
 	rcu_assign_pointer(tp->funcs, tp_funcs);
 	release_probes(old);
 	return 0;

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 3/4] x86/static_call: Add out-of-line static call implementation
  2018-11-26 13:54 ` [PATCH v2 3/4] x86/static_call: Add out-of-line static call implementation Josh Poimboeuf
@ 2018-11-26 15:43   ` Peter Zijlstra
  2018-11-26 16:19     ` Steven Rostedt
  0 siblings, 1 reply; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-26 15:43 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 07:54:59AM -0600, Josh Poimboeuf wrote:

> +void static_call_bp_handler(void);
> +void *bp_handler_dest;
> +
> +asm(".pushsection .text, \"ax\"						\n"
> +    ".globl static_call_bp_handler					\n"
> +    ".type static_call_bp_handler, @function				\n"
> +    "static_call_bp_handler:						\n"
> +    "ANNOTATE_RETPOLINE_SAFE						\n"
> +    "jmp *bp_handler_dest						\n"
> +    ".popsection							\n");
> +
> +void arch_static_call_transform(void *site, void *tramp, void *func)
> +{
> +	s32 dest_relative;
> +	unsigned long insn;
> +	unsigned char insn_opcode;
> +	unsigned char opcodes[CALL_INSN_SIZE];
> +
> +	insn = (unsigned long)tramp;
> +
> +	mutex_lock(&text_mutex);
> +
> +	insn_opcode = *(unsigned char *)insn;
> +	if (insn_opcode != 0xe8 && insn_opcode != 0xe9) {
> +		WARN_ONCE(1, "unexpected static call insn opcode 0x%x at %pS",
> +			  insn_opcode, (void *)insn);
> +		goto done;
> +	}
> +
> +	dest_relative = (long)(func) - (long)(insn + CALL_INSN_SIZE);
> +
> +	opcodes[0] = insn_opcode;
> +	memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
> +
> +	/* Set up the variable for the breakpoint handler: */
> +	bp_handler_dest = func;
> +
> +	/* Patch the call site: */
> +	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
> +		     static_call_bp_handler);

I'm confused by the whole static_call_bp_handler thing; why not jump
straight to @func ?

Also, what guarantees this other thread will have gotten from
static_call_bp_handler and executed the actual indirect JMP instruction
by the time we re-write @bp_handler_dest again?

> +done:
> +	mutex_unlock(&text_mutex);
> +}

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 13:55 ` [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64 Josh Poimboeuf
@ 2018-11-26 16:02   ` Peter Zijlstra
  2018-11-26 17:10     ` Josh Poimboeuf
  2018-11-26 16:08   ` Peter Zijlstra
  1 sibling, 1 reply; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-26 16:02 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> index 8026d176f25c..d3869295b88d 100644
> --- a/arch/x86/kernel/static_call.c
> +++ b/arch/x86/kernel/static_call.c
> @@ -9,13 +9,21 @@
>  
>  void static_call_bp_handler(void);
>  void *bp_handler_dest;
> +void *bp_handler_continue;
>  
>  asm(".pushsection .text, \"ax\"						\n"
>      ".globl static_call_bp_handler					\n"
>      ".type static_call_bp_handler, @function				\n"
>      "static_call_bp_handler:						\n"
> -    "ANNOTATE_RETPOLINE_SAFE						\n"
> +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> +    ANNOTATE_RETPOLINE_SAFE
> +    "call *bp_handler_dest						\n"
> +    ANNOTATE_RETPOLINE_SAFE
> +    "jmp *bp_handler_continue						\n"
> +#else /* !CONFIG_HAVE_STATIC_CALL_INLINE */
> +    ANNOTATE_RETPOLINE_SAFE
>      "jmp *bp_handler_dest						\n"
> +#endif
>      ".popsection							\n");
>  
>  void arch_static_call_transform(void *site, void *tramp, void *func)
> @@ -25,7 +33,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
>  	unsigned char insn_opcode;
>  	unsigned char opcodes[CALL_INSN_SIZE];
>  
> -	insn = (unsigned long)tramp;
> +	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> +		insn = (unsigned long)site;
> +	else
> +		insn = (unsigned long)tramp;
>  
>  	mutex_lock(&text_mutex);
>  
> @@ -41,8 +52,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
>  	opcodes[0] = insn_opcode;
>  	memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
>  
> -	/* Set up the variable for the breakpoint handler: */
> +	/* Set up the variables for the breakpoint handler: */
>  	bp_handler_dest = func;
> +	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> +		bp_handler_continue = (void *)(insn + CALL_INSN_SIZE);
>  
>  	/* Patch the call site: */
>  	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,

OK, so this is where that static_call_bp_handler comes from; you need
that CALL to frob the stack.

But I still think it is broken; consider:

	CPU0				CPU1

	bp_handler = ponies;

	text_poke_bp(, &static_call_bp_handler)
	  text_poke(&int3);
	  on_each_cpu(sync)
	  				<IPI>
					  ...
					</IPI>

	  text_poke(/* all but first bytes */)
	  on_each_cpu(sync)
	  				<IPI>
					  ...
					</IPI>

	  				<int3>
					  pt_regs->ip = &static_call_bp_handler
					</int3>

					// VCPU takes a nap...
	  text_poke(/* first byte */)
	  on_each_cpu(sync)
	  				<IPI>
					  ...
					</IPI>

					// VCPU sleeps more
	bp_handler = unicorn;

					CALL unicorn

*whoops*

Now, granted, that is all rather 'unlikely', but that never stopped
Murphy.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 13:55 ` [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64 Josh Poimboeuf
  2018-11-26 16:02   ` Peter Zijlstra
@ 2018-11-26 16:08   ` Peter Zijlstra
  2018-11-26 16:11     ` Ard Biesheuvel
  1 sibling, 1 reply; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-26 16:08 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> +void arch_static_call_defuse_tramp(void *site, void *tramp)
> +{
> +	unsigned short opcode = INSN_UD2;
> +
> +	mutex_lock(&text_mutex);
> +	text_poke((void *)tramp, &opcode, 2);
> +	mutex_unlock(&text_mutex);
> +}
> +#endif

I would rather think that makes the trampoline _more_ dangerous, rather
than less so.

My dictionary sayeth:

  defuse: verb

    - remove the fuse from (an explosive device) in order to prevent it
      from exploding.

    - make (a situation) less tense or dangerous

patching in an UD2 seems to do the exact opposite.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 16:08   ` Peter Zijlstra
@ 2018-11-26 16:11     ` Ard Biesheuvel
  2018-11-26 16:33       ` Andy Lutomirski
  2018-11-26 16:39       ` Peter Zijlstra
  0 siblings, 2 replies; 120+ messages in thread
From: Ard Biesheuvel @ 2018-11-26 16:11 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Josh Poimboeuf, the arch/x86 maintainers,
	Linux Kernel Mailing List, Andy Lutomirski, Steven Rostedt,
	Ingo Molnar, Thomas Gleixner, Linus Torvalds, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	Jessica Yu, H. Peter Anvin

On Mon, 26 Nov 2018 at 17:08, Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > +void arch_static_call_defuse_tramp(void *site, void *tramp)
> > +{
> > +     unsigned short opcode = INSN_UD2;
> > +
> > +     mutex_lock(&text_mutex);
> > +     text_poke((void *)tramp, &opcode, 2);
> > +     mutex_unlock(&text_mutex);
> > +}
> > +#endif
>
> I would rather think that makes the trampoline _more_ dangerous, rather
> than less so.
>
> My dictionary sayeth:
>
>   defuse: verb
>
>     - remove the fuse from (an explosive device) in order to prevent it
>       from exploding.
>
>     - make (a situation) less tense or dangerous
>
> patching in an UD2 seems to do the exact opposite.

That is my fault.

The original name was 'poison' iirc, but on arm64, we need to retain
the trampoline for cases where the direct branch is out of range, and
so poisoning is semantically inaccurate.

But since you opened your dictionary anyway, any better suggestions? :-)

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 3/4] x86/static_call: Add out-of-line static call implementation
  2018-11-26 15:43   ` Peter Zijlstra
@ 2018-11-26 16:19     ` Steven Rostedt
  0 siblings, 0 replies; 120+ messages in thread
From: Steven Rostedt @ 2018-11-26 16:19 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Josh Poimboeuf, x86, linux-kernel, Ard Biesheuvel,
	Andy Lutomirski, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, 26 Nov 2018 16:43:56 +0100
Peter Zijlstra <peterz@infradead.org> wrote:


> > +	/* Patch the call site: */
> > +	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
> > +		     static_call_bp_handler);  
> 
> I'm confused by the whole static_call_bp_handler thing; why not jump
> straight to @func ?

Interesting, that might work. I can give it a try.

-- Steve

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 16:11     ` Ard Biesheuvel
@ 2018-11-26 16:33       ` Andy Lutomirski
  2018-11-26 16:39       ` Peter Zijlstra
  1 sibling, 0 replies; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-26 16:33 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Peter Zijlstra, Josh Poimboeuf, X86 ML, LKML, Andrew Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Mon, Nov 26, 2018 at 8:11 AM Ard Biesheuvel
<ard.biesheuvel@linaro.org> wrote:
>
> On Mon, 26 Nov 2018 at 17:08, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > > +void arch_static_call_defuse_tramp(void *site, void *tramp)
> > > +{
> > > +     unsigned short opcode = INSN_UD2;
> > > +
> > > +     mutex_lock(&text_mutex);
> > > +     text_poke((void *)tramp, &opcode, 2);
> > > +     mutex_unlock(&text_mutex);
> > > +}
> > > +#endif
> >
> > I would rather think that makes the trampoline _more_ dangerous, rather
> > than less so.
> >
> > My dictionary sayeth:
> >
> >   defuse: verb
> >
> >     - remove the fuse from (an explosive device) in order to prevent it
> >       from exploding.
> >
> >     - make (a situation) less tense or dangerous
> >
> > patching in an UD2 seems to do the exact opposite.
>
> That is my fault.
>
> The original name was 'poison' iirc, but on arm64, we need to retain
> the trampoline for cases where the direct branch is out of range, and
> so poisoning is semantically inaccurate.
>
> But since you opened your dictionary anyway, any better suggestions? :-)

Release?  Finish?

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 16:11     ` Ard Biesheuvel
  2018-11-26 16:33       ` Andy Lutomirski
@ 2018-11-26 16:39       ` Peter Zijlstra
  2018-11-26 16:44         ` Josh Poimboeuf
  1 sibling, 1 reply; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-26 16:39 UTC (permalink / raw)
  To: Ard Biesheuvel
  Cc: Josh Poimboeuf, the arch/x86 maintainers,
	Linux Kernel Mailing List, Andy Lutomirski, Steven Rostedt,
	Ingo Molnar, Thomas Gleixner, Linus Torvalds, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 05:11:05PM +0100, Ard Biesheuvel wrote:
> On Mon, 26 Nov 2018 at 17:08, Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > > +void arch_static_call_defuse_tramp(void *site, void *tramp)
> > > +{
> > > +     unsigned short opcode = INSN_UD2;
> > > +
> > > +     mutex_lock(&text_mutex);
> > > +     text_poke((void *)tramp, &opcode, 2);
> > > +     mutex_unlock(&text_mutex);
> > > +}
> > > +#endif
> >
> > I would rather think that makes the trampoline _more_ dangerous, rather
> > than less so.
> >
> > My dictionary sayeth:
> >
> >   defuse: verb
> >
> >     - remove the fuse from (an explosive device) in order to prevent it
> >       from exploding.
> >
> >     - make (a situation) less tense or dangerous
> >
> > patching in an UD2 seems to do the exact opposite.
> 
> That is my fault.
> 
> The original name was 'poison' iirc, but on arm64, we need to retain
> the trampoline for cases where the direct branch is out of range, and
> so poisoning is semantically inaccurate.
> 
> But since you opened your dictionary anyway, any better suggestions? :-)

I was leaning towards: "prime", but I'm not entirely sure that works
with your case.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 16:39       ` Peter Zijlstra
@ 2018-11-26 16:44         ` Josh Poimboeuf
  0 siblings, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 16:44 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Ard Biesheuvel, the arch/x86 maintainers,
	Linux Kernel Mailing List, Andy Lutomirski, Steven Rostedt,
	Ingo Molnar, Thomas Gleixner, Linus Torvalds, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 05:39:23PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 26, 2018 at 05:11:05PM +0100, Ard Biesheuvel wrote:
> > On Mon, 26 Nov 2018 at 17:08, Peter Zijlstra <peterz@infradead.org> wrote:
> > >
> > > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > > > +void arch_static_call_defuse_tramp(void *site, void *tramp)
> > > > +{
> > > > +     unsigned short opcode = INSN_UD2;
> > > > +
> > > > +     mutex_lock(&text_mutex);
> > > > +     text_poke((void *)tramp, &opcode, 2);
> > > > +     mutex_unlock(&text_mutex);
> > > > +}
> > > > +#endif
> > >
> > > I would rather think that makes the trampoline _more_ dangerous, rather
> > > than less so.
> > >
> > > My dictionary sayeth:
> > >
> > >   defuse: verb
> > >
> > >     - remove the fuse from (an explosive device) in order to prevent it
> > >       from exploding.
> > >
> > >     - make (a situation) less tense or dangerous
> > >
> > > patching in an UD2 seems to do the exact opposite.
> > 
> > That is my fault.
> > 
> > The original name was 'poison' iirc, but on arm64, we need to retain
> > the trampoline for cases where the direct branch is out of range, and
> > so poisoning is semantically inaccurate.
> > 
> > But since you opened your dictionary anyway, any better suggestions? :-)
> 
> I was leaning towards: "prime", but I'm not entirely sure that works
> with your case.

Maybe we should just go back to "poison", along with a comment that it
will not necessarily be poisoned for all arches.  I think "poison" at
least describes the intent, if not always the implementation.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 16:02   ` Peter Zijlstra
@ 2018-11-26 17:10     ` Josh Poimboeuf
  2018-11-26 17:56       ` Josh Poimboeuf
  2018-11-26 18:28       ` Andy Lutomirski
  0 siblings, 2 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 17:10 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > index 8026d176f25c..d3869295b88d 100644
> > --- a/arch/x86/kernel/static_call.c
> > +++ b/arch/x86/kernel/static_call.c
> > @@ -9,13 +9,21 @@
> >  
> >  void static_call_bp_handler(void);
> >  void *bp_handler_dest;
> > +void *bp_handler_continue;
> >  
> >  asm(".pushsection .text, \"ax\"						\n"
> >      ".globl static_call_bp_handler					\n"
> >      ".type static_call_bp_handler, @function				\n"
> >      "static_call_bp_handler:						\n"
> > -    "ANNOTATE_RETPOLINE_SAFE						\n"
> > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > +    ANNOTATE_RETPOLINE_SAFE
> > +    "call *bp_handler_dest						\n"
> > +    ANNOTATE_RETPOLINE_SAFE
> > +    "jmp *bp_handler_continue						\n"
> > +#else /* !CONFIG_HAVE_STATIC_CALL_INLINE */
> > +    ANNOTATE_RETPOLINE_SAFE
> >      "jmp *bp_handler_dest						\n"
> > +#endif
> >      ".popsection							\n");
> >  
> >  void arch_static_call_transform(void *site, void *tramp, void *func)
> > @@ -25,7 +33,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
> >  	unsigned char insn_opcode;
> >  	unsigned char opcodes[CALL_INSN_SIZE];
> >  
> > -	insn = (unsigned long)tramp;
> > +	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> > +		insn = (unsigned long)site;
> > +	else
> > +		insn = (unsigned long)tramp;
> >  
> >  	mutex_lock(&text_mutex);
> >  
> > @@ -41,8 +52,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
> >  	opcodes[0] = insn_opcode;
> >  	memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
> >  
> > -	/* Set up the variable for the breakpoint handler: */
> > +	/* Set up the variables for the breakpoint handler: */
> >  	bp_handler_dest = func;
> > +	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> > +		bp_handler_continue = (void *)(insn + CALL_INSN_SIZE);
> >  
> >  	/* Patch the call site: */
> >  	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
> 
> OK, so this is where that static_call_bp_handler comes from; you need
> that CALL to frob the stack.
> 
> But I still think it is broken; consider:
> 
> 	CPU0				CPU1
> 
> 	bp_handler = ponies;
> 
> 	text_poke_bp(, &static_call_bp_handler)
> 	  text_poke(&int3);
> 	  on_each_cpu(sync)
> 	  				<IPI>
> 					  ...
> 					</IPI>
> 
> 	  text_poke(/* all but first bytes */)
> 	  on_each_cpu(sync)
> 	  				<IPI>
> 					  ...
> 					</IPI>
> 
> 	  				<int3>
> 					  pt_regs->ip = &static_call_bp_handler
> 					</int3>
> 
> 					// VCPU takes a nap...
> 	  text_poke(/* first byte */)
> 	  on_each_cpu(sync)
> 	  				<IPI>
> 					  ...
> 					</IPI>
> 
> 					// VCPU sleeps more
> 	bp_handler = unicorn;
> 
> 					CALL unicorn
> 
> *whoops*
> 
> Now, granted, that is all rather 'unlikely', but that never stopped
> Murphy.

Good find, thanks Peter.

As we discussed on IRC, we'll need to fix this from within the int3
exception handler by faking the call: putting a fake return address on
the stack (pointing to right after the call) and setting regs->ip to the
called function.

And for the out-of-line case we can just jump straight to the function,
so the function itself will be the text_poke_bp() "handler".

So the static_call_bp_handler() trampoline will go away.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 17:10     ` Josh Poimboeuf
@ 2018-11-26 17:56       ` Josh Poimboeuf
  2018-11-26 20:00         ` Peter Zijlstra
  2018-11-26 20:08         ` Peter Zijlstra
  2018-11-26 18:28       ` Andy Lutomirski
  1 sibling, 2 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 17:56 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 11:10:36AM -0600, Josh Poimboeuf wrote:
> On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > > index 8026d176f25c..d3869295b88d 100644
> > > --- a/arch/x86/kernel/static_call.c
> > > +++ b/arch/x86/kernel/static_call.c
> > > @@ -9,13 +9,21 @@
> > >  
> > >  void static_call_bp_handler(void);
> > >  void *bp_handler_dest;
> > > +void *bp_handler_continue;
> > >  
> > >  asm(".pushsection .text, \"ax\"						\n"
> > >      ".globl static_call_bp_handler					\n"
> > >      ".type static_call_bp_handler, @function				\n"
> > >      "static_call_bp_handler:						\n"
> > > -    "ANNOTATE_RETPOLINE_SAFE						\n"
> > > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > > +    ANNOTATE_RETPOLINE_SAFE
> > > +    "call *bp_handler_dest						\n"
> > > +    ANNOTATE_RETPOLINE_SAFE
> > > +    "jmp *bp_handler_continue						\n"
> > > +#else /* !CONFIG_HAVE_STATIC_CALL_INLINE */
> > > +    ANNOTATE_RETPOLINE_SAFE
> > >      "jmp *bp_handler_dest						\n"
> > > +#endif
> > >      ".popsection							\n");
> > >  
> > >  void arch_static_call_transform(void *site, void *tramp, void *func)
> > > @@ -25,7 +33,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
> > >  	unsigned char insn_opcode;
> > >  	unsigned char opcodes[CALL_INSN_SIZE];
> > >  
> > > -	insn = (unsigned long)tramp;
> > > +	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> > > +		insn = (unsigned long)site;
> > > +	else
> > > +		insn = (unsigned long)tramp;
> > >  
> > >  	mutex_lock(&text_mutex);
> > >  
> > > @@ -41,8 +52,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
> > >  	opcodes[0] = insn_opcode;
> > >  	memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
> > >  
> > > -	/* Set up the variable for the breakpoint handler: */
> > > +	/* Set up the variables for the breakpoint handler: */
> > >  	bp_handler_dest = func;
> > > +	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> > > +		bp_handler_continue = (void *)(insn + CALL_INSN_SIZE);
> > >  
> > >  	/* Patch the call site: */
> > >  	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
> > 
> > OK, so this is where that static_call_bp_handler comes from; you need
> > that CALL to frob the stack.
> > 
> > But I still think it is broken; consider:
> > 
> > 	CPU0				CPU1
> > 
> > 	bp_handler = ponies;
> > 
> > 	text_poke_bp(, &static_call_bp_handler)
> > 	  text_poke(&int3);
> > 	  on_each_cpu(sync)
> > 	  				<IPI>
> > 					  ...
> > 					</IPI>
> > 
> > 	  text_poke(/* all but first bytes */)
> > 	  on_each_cpu(sync)
> > 	  				<IPI>
> > 					  ...
> > 					</IPI>
> > 
> > 	  				<int3>
> > 					  pt_regs->ip = &static_call_bp_handler
> > 					</int3>
> > 
> > 					// VCPU takes a nap...
> > 	  text_poke(/* first byte */)
> > 	  on_each_cpu(sync)
> > 	  				<IPI>
> > 					  ...
> > 					</IPI>
> > 
> > 					// VCPU sleeps more
> > 	bp_handler = unicorn;
> > 
> > 					CALL unicorn
> > 
> > *whoops*
> > 
> > Now, granted, that is all rather 'unlikely', but that never stopped
> > Murphy.
> 
> Good find, thanks Peter.
> 
> As we discussed on IRC, we'll need to fix this from within the int3
> exception handler by faking the call: putting a fake return address on
> the stack (pointing to right after the call) and setting regs->ip to the
> called function.
> 
> And for the out-of-line case we can just jump straight to the function,
> so the function itself will be the text_poke_bp() "handler".
> 
> So the static_call_bp_handler() trampoline will go away.

Peter suggested updating the text_poke_bp() interface to add a handler
which is called from int3 context.  This seems to work.

diff --git a/arch/x86/include/asm/text-patching.h b/arch/x86/include/asm/text-patching.h
index e85ff65c43c3..7fcaa37c1876 100644
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -20,6 +20,8 @@ static inline void apply_paravirt(struct paravirt_patch_site *start,
 
 extern void *text_poke_early(void *addr, const void *opcode, size_t len);
 
+typedef void (*bp_handler_t)(struct pt_regs *regs);
+
 /*
  * Clear and restore the kernel write-protection flag on the local CPU.
  * Allows the kernel to edit read-only pages.
@@ -36,7 +38,8 @@ extern void *text_poke_early(void *addr, const void *opcode, size_t len);
  */
 extern void *text_poke(void *addr, const void *opcode, size_t len);
 extern int poke_int3_handler(struct pt_regs *regs);
-extern void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler);
+extern void *text_poke_bp(void *addr, const void *opcode, size_t len,
+			  bp_handler_t handler, void *resume);
 extern int after_bootmem;
 
 #endif /* _ASM_X86_TEXT_PATCHING_H */
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index ebeac487a20c..b6fb645488be 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -738,7 +738,8 @@ static void do_sync_core(void *info)
 }
 
 static bool bp_patching_in_progress;
-static void *bp_int3_handler, *bp_int3_addr;
+static void *bp_int3_resume, *bp_int3_addr;
+static bp_handler_t bp_int3_handler;
 
 int poke_int3_handler(struct pt_regs *regs)
 {
@@ -746,11 +747,11 @@ int poke_int3_handler(struct pt_regs *regs)
 	 * Having observed our INT3 instruction, we now must observe
 	 * bp_patching_in_progress.
 	 *
-	 * 	in_progress = TRUE		INT3
-	 * 	WMB				RMB
-	 * 	write INT3			if (in_progress)
+	 *	in_progress = TRUE		INT3
+	 *	WMB				RMB
+	 *	write INT3			if (in_progress)
 	 *
-	 * Idem for bp_int3_handler.
+	 * Idem for bp_int3_resume.
 	 */
 	smp_rmb();
 
@@ -760,8 +761,10 @@ int poke_int3_handler(struct pt_regs *regs)
 	if (user_mode(regs) || regs->ip != (unsigned long)bp_int3_addr)
 		return 0;
 
-	/* set up the specified breakpoint handler */
-	regs->ip = (unsigned long) bp_int3_handler;
+	if (bp_int3_handler)
+		bp_int3_handler(regs);
+
+	regs->ip = (unsigned long)bp_int3_resume;
 
 	return 1;
 
@@ -772,7 +775,8 @@ int poke_int3_handler(struct pt_regs *regs)
  * @addr:	address to patch
  * @opcode:	opcode of new instruction
  * @len:	length to copy
- * @handler:	address to jump to when the temporary breakpoint is hit
+ * @handler:	handler to call from int3 context (optional)
+ * @resume:	address to jump to when returning from int3 context
  *
  * Modify multi-byte instruction by using int3 breakpoint on SMP.
  * We completely avoid stop_machine() here, and achieve the
@@ -787,11 +791,13 @@ int poke_int3_handler(struct pt_regs *regs)
  *	  replacing opcode
  *	- sync cores
  */
-void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler)
+void *text_poke_bp(void *addr, const void *opcode, size_t len,
+		   bp_handler_t handler, void *resume)
 {
 	unsigned char int3 = 0xcc;
 
 	bp_int3_handler = handler;
+	bp_int3_resume = resume;
 	bp_int3_addr = (u8 *)addr + sizeof(int3);
 	bp_patching_in_progress = true;
 
diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
index aac0c1f7e354..1a54c5c6d9f3 100644
--- a/arch/x86/kernel/jump_label.c
+++ b/arch/x86/kernel/jump_label.c
@@ -90,7 +90,7 @@ static void __ref __jump_label_transform(struct jump_entry *entry,
 		return;
 	}
 
-	text_poke_bp((void *)jump_entry_code(entry), code, JUMP_LABEL_NOP_SIZE,
+	text_poke_bp((void *)jump_entry_code(entry), code, JUMP_LABEL_NOP_SIZE, NULL,
 		     (void *)jump_entry_code(entry) + JUMP_LABEL_NOP_SIZE);
 }
 
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 40b16b270656..5787f48be243 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -446,7 +446,7 @@ void arch_optimize_kprobes(struct list_head *oplist)
 		insn_buf[0] = RELATIVEJUMP_OPCODE;
 		*(s32 *)(&insn_buf[1]) = rel;
 
-		text_poke_bp(op->kp.addr, insn_buf, RELATIVEJUMP_SIZE,
+		text_poke_bp(op->kp.addr, insn_buf, RELATIVEJUMP_SIZE, NULL,
 			     op->optinsn.insn);
 
 		list_del_init(&op->list);
@@ -461,7 +461,7 @@ void arch_unoptimize_kprobe(struct optimized_kprobe *op)
 	/* Set int3 to first byte for kprobes */
 	insn_buf[0] = BREAKPOINT_INSTRUCTION;
 	memcpy(insn_buf + 1, op->optinsn.copied_insn, RELATIVE_ADDR_SIZE);
-	text_poke_bp(op->kp.addr, insn_buf, RELATIVEJUMP_SIZE,
+	text_poke_bp(op->kp.addr, insn_buf, RELATIVEJUMP_SIZE, NULL,
 		     op->optinsn.insn);
 }
 
diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
index d3869295b88d..8fd6c8556750 100644
--- a/arch/x86/kernel/static_call.c
+++ b/arch/x86/kernel/static_call.c
@@ -7,24 +7,19 @@
 
 #define CALL_INSN_SIZE 5
 
-void static_call_bp_handler(void);
-void *bp_handler_dest;
-void *bp_handler_continue;
+unsigned long bp_handler_call_return_addr;
 
-asm(".pushsection .text, \"ax\"						\n"
-    ".globl static_call_bp_handler					\n"
-    ".type static_call_bp_handler, @function				\n"
-    "static_call_bp_handler:						\n"
+static void static_call_bp_handler(struct pt_regs *regs)
+{
 #ifdef CONFIG_HAVE_STATIC_CALL_INLINE
-    ANNOTATE_RETPOLINE_SAFE
-    "call *bp_handler_dest						\n"
-    ANNOTATE_RETPOLINE_SAFE
-    "jmp *bp_handler_continue						\n"
-#else /* !CONFIG_HAVE_STATIC_CALL_INLINE */
-    ANNOTATE_RETPOLINE_SAFE
-    "jmp *bp_handler_dest						\n"
+	/*
+	 * Push the return address on the stack so the "called" function will
+	 * return to immediately after the call site.
+	 */
+	regs->sp -= sizeof(long);
+	*(unsigned long *)regs->sp = bp_handler_call_return_addr;
 #endif
-    ".popsection							\n");
+}
 
 void arch_static_call_transform(void *site, void *tramp, void *func)
 {
@@ -52,14 +47,12 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
 	opcodes[0] = insn_opcode;
 	memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
 
-	/* Set up the variables for the breakpoint handler: */
-	bp_handler_dest = func;
 	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
-		bp_handler_continue = (void *)(insn + CALL_INSN_SIZE);
+		bp_handler_call_return_addr = insn + CALL_INSN_SIZE;
 
 	/* Patch the call site: */
 	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
-		     static_call_bp_handler);
+		     static_call_bp_handler, func);
 
 done:
 	mutex_unlock(&text_mutex);

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 17:10     ` Josh Poimboeuf
  2018-11-26 17:56       ` Josh Poimboeuf
@ 2018-11-26 18:28       ` Andy Lutomirski
  2018-11-26 20:14         ` Josh Poimboeuf
  1 sibling, 1 reply; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-26 18:28 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Peter Zijlstra, X86 ML, LKML, Ard Biesheuvel, Andrew Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Mon, Nov 26, 2018 at 9:10 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > > index 8026d176f25c..d3869295b88d 100644
> > > --- a/arch/x86/kernel/static_call.c
> > > +++ b/arch/x86/kernel/static_call.c
> > > @@ -9,13 +9,21 @@
> > >
> > >  void static_call_bp_handler(void);
> > >  void *bp_handler_dest;
> > > +void *bp_handler_continue;
> > >
> > >  asm(".pushsection .text, \"ax\"                                            \n"
> > >      ".globl static_call_bp_handler                                 \n"
> > >      ".type static_call_bp_handler, @function                               \n"
> > >      "static_call_bp_handler:                                               \n"
> > > -    "ANNOTATE_RETPOLINE_SAFE                                               \n"
> > > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > > +    ANNOTATE_RETPOLINE_SAFE
> > > +    "call *bp_handler_dest                                         \n"
> > > +    ANNOTATE_RETPOLINE_SAFE
> > > +    "jmp *bp_handler_continue                                              \n"
> > > +#else /* !CONFIG_HAVE_STATIC_CALL_INLINE */
> > > +    ANNOTATE_RETPOLINE_SAFE
> > >      "jmp *bp_handler_dest                                          \n"
> > > +#endif
> > >      ".popsection                                                   \n");
> > >
> > >  void arch_static_call_transform(void *site, void *tramp, void *func)
> > > @@ -25,7 +33,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
> > >     unsigned char insn_opcode;
> > >     unsigned char opcodes[CALL_INSN_SIZE];
> > >
> > > -   insn = (unsigned long)tramp;
> > > +   if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> > > +           insn = (unsigned long)site;
> > > +   else
> > > +           insn = (unsigned long)tramp;
> > >
> > >     mutex_lock(&text_mutex);
> > >
> > > @@ -41,8 +52,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
> > >     opcodes[0] = insn_opcode;
> > >     memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
> > >
> > > -   /* Set up the variable for the breakpoint handler: */
> > > +   /* Set up the variables for the breakpoint handler: */
> > >     bp_handler_dest = func;
> > > +   if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> > > +           bp_handler_continue = (void *)(insn + CALL_INSN_SIZE);
> > >
> > >     /* Patch the call site: */
> > >     text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
> >
> > OK, so this is where that static_call_bp_handler comes from; you need
> > that CALL to frob the stack.
> >
> > But I still think it is broken; consider:
> >
> >       CPU0                            CPU1
> >
> >       bp_handler = ponies;
> >
> >       text_poke_bp(, &static_call_bp_handler)
> >         text_poke(&int3);
> >         on_each_cpu(sync)
> >                                       <IPI>
> >                                         ...
> >                                       </IPI>
> >
> >         text_poke(/* all but first bytes */)
> >         on_each_cpu(sync)
> >                                       <IPI>
> >                                         ...
> >                                       </IPI>
> >
> >                                       <int3>
> >                                         pt_regs->ip = &static_call_bp_handler
> >                                       </int3>
> >
> >                                       // VCPU takes a nap...
> >         text_poke(/* first byte */)
> >         on_each_cpu(sync)
> >                                       <IPI>
> >                                         ...
> >                                       </IPI>
> >
> >                                       // VCPU sleeps more
> >       bp_handler = unicorn;
> >
> >                                       CALL unicorn
> >
> > *whoops*
> >
> > Now, granted, that is all rather 'unlikely', but that never stopped
> > Murphy.
>
> Good find, thanks Peter.
>
> As we discussed on IRC, we'll need to fix this from within the int3
> exception handler by faking the call: putting a fake return address on
> the stack (pointing to right after the call) and setting regs->ip to the
> called function.

Can you add a comment that it will need updating when kernel CET is added?

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 17:56       ` Josh Poimboeuf
@ 2018-11-26 20:00         ` Peter Zijlstra
  2018-11-26 20:08         ` Peter Zijlstra
  1 sibling, 0 replies; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-26 20:00 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 11:56:24AM -0600, Josh Poimboeuf wrote:
> Peter suggested updating the text_poke_bp() interface to add a handler
> which is called from int3 context.  This seems to work.

> @@ -760,8 +761,10 @@ int poke_int3_handler(struct pt_regs *regs)
>  	if (user_mode(regs) || regs->ip != (unsigned long)bp_int3_addr)
>  		return 0;
>  
> -	/* set up the specified breakpoint handler */
> -	regs->ip = (unsigned long) bp_int3_handler;
> +	if (bp_int3_handler)
> +		bp_int3_handler(regs);
> +
> +	regs->ip = (unsigned long)bp_int3_resume;
>  
>  	return 1;
>  

Peter also suggested you write that like:

	if (bp_int3_handler)
		bp_int3_handler(regs, resume);
	else
		regs->ip = resume;

That allows 'abusing' @resume as 'data' pointer for @handler. Which
allows for more complicated handlers.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 17:56       ` Josh Poimboeuf
  2018-11-26 20:00         ` Peter Zijlstra
@ 2018-11-26 20:08         ` Peter Zijlstra
  2018-11-26 21:26           ` Josh Poimboeuf
  1 sibling, 1 reply; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-26 20:08 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 11:56:24AM -0600, Josh Poimboeuf wrote:
> diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> index d3869295b88d..8fd6c8556750 100644
> --- a/arch/x86/kernel/static_call.c
> +++ b/arch/x86/kernel/static_call.c
> @@ -7,24 +7,19 @@
>  
>  #define CALL_INSN_SIZE 5
>  
> +unsigned long bp_handler_call_return_addr;
>  
> +static void static_call_bp_handler(struct pt_regs *regs)
> +{
>  #ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> +	/*
> +	 * Push the return address on the stack so the "called" function will
> +	 * return to immediately after the call site.
> +	 */
> +	regs->sp -= sizeof(long);
> +	*(unsigned long *)regs->sp = bp_handler_call_return_addr;
>  #endif
> +}
>  
>  void arch_static_call_transform(void *site, void *tramp, void *func)
>  {
> @@ -52,14 +47,12 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
>  	opcodes[0] = insn_opcode;
>  	memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
>  
>  	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> +		bp_handler_call_return_addr = insn + CALL_INSN_SIZE;
>  
>  	/* Patch the call site: */
>  	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
> -		     static_call_bp_handler);
> +		     static_call_bp_handler, func);
>  
>  done:
>  	mutex_unlock(&text_mutex);


like maybe something along the lines of:

struct sc_data {
	unsigned long ret;
	unsigned long ip;
};

void sc_handler(struct pt_regs *regs, void *data)
{
	struct sc_data *scd = data;

	regs->sp -= sizeof(long);
	*(unsigned long *)regs->sp = scd->ret;
	regs->ip = scd->ip;
}

arch_static_call_transform()
{
	...

	scd = (struct sc_data){
		.ret = insn + CALL_INSN_SIZE,
		.ip = (unsigned long)func,
	};

	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
			sc_handler, (void *)&scd);

	...
}

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 18:28       ` Andy Lutomirski
@ 2018-11-26 20:14         ` Josh Poimboeuf
  2018-11-27  8:46           ` Peter Zijlstra
  0 siblings, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 20:14 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Peter Zijlstra, X86 ML, LKML, Ard Biesheuvel, Steven Rostedt,
	Ingo Molnar, Thomas Gleixner, Linus Torvalds, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	jeyu, H. Peter Anvin

On Mon, Nov 26, 2018 at 10:28:08AM -0800, Andy Lutomirski wrote:
> On Mon, Nov 26, 2018 at 9:10 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > On Mon, Nov 26, 2018 at 05:02:17PM +0100, Peter Zijlstra wrote:
> > > On Mon, Nov 26, 2018 at 07:55:00AM -0600, Josh Poimboeuf wrote:
> > > > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > > > index 8026d176f25c..d3869295b88d 100644
> > > > --- a/arch/x86/kernel/static_call.c
> > > > +++ b/arch/x86/kernel/static_call.c
> > > > @@ -9,13 +9,21 @@
> > > >
> > > >  void static_call_bp_handler(void);
> > > >  void *bp_handler_dest;
> > > > +void *bp_handler_continue;
> > > >
> > > >  asm(".pushsection .text, \"ax\"                                            \n"
> > > >      ".globl static_call_bp_handler                                 \n"
> > > >      ".type static_call_bp_handler, @function                               \n"
> > > >      "static_call_bp_handler:                                               \n"
> > > > -    "ANNOTATE_RETPOLINE_SAFE                                               \n"
> > > > +#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > > > +    ANNOTATE_RETPOLINE_SAFE
> > > > +    "call *bp_handler_dest                                         \n"
> > > > +    ANNOTATE_RETPOLINE_SAFE
> > > > +    "jmp *bp_handler_continue                                              \n"
> > > > +#else /* !CONFIG_HAVE_STATIC_CALL_INLINE */
> > > > +    ANNOTATE_RETPOLINE_SAFE
> > > >      "jmp *bp_handler_dest                                          \n"
> > > > +#endif
> > > >      ".popsection                                                   \n");
> > > >
> > > >  void arch_static_call_transform(void *site, void *tramp, void *func)
> > > > @@ -25,7 +33,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
> > > >     unsigned char insn_opcode;
> > > >     unsigned char opcodes[CALL_INSN_SIZE];
> > > >
> > > > -   insn = (unsigned long)tramp;
> > > > +   if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> > > > +           insn = (unsigned long)site;
> > > > +   else
> > > > +           insn = (unsigned long)tramp;
> > > >
> > > >     mutex_lock(&text_mutex);
> > > >
> > > > @@ -41,8 +52,10 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
> > > >     opcodes[0] = insn_opcode;
> > > >     memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
> > > >
> > > > -   /* Set up the variable for the breakpoint handler: */
> > > > +   /* Set up the variables for the breakpoint handler: */
> > > >     bp_handler_dest = func;
> > > > +   if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> > > > +           bp_handler_continue = (void *)(insn + CALL_INSN_SIZE);
> > > >
> > > >     /* Patch the call site: */
> > > >     text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
> > >
> > > OK, so this is where that static_call_bp_handler comes from; you need
> > > that CALL to frob the stack.
> > >
> > > But I still think it is broken; consider:
> > >
> > >       CPU0                            CPU1
> > >
> > >       bp_handler = ponies;
> > >
> > >       text_poke_bp(, &static_call_bp_handler)
> > >         text_poke(&int3);
> > >         on_each_cpu(sync)
> > >                                       <IPI>
> > >                                         ...
> > >                                       </IPI>
> > >
> > >         text_poke(/* all but first bytes */)
> > >         on_each_cpu(sync)
> > >                                       <IPI>
> > >                                         ...
> > >                                       </IPI>
> > >
> > >                                       <int3>
> > >                                         pt_regs->ip = &static_call_bp_handler
> > >                                       </int3>
> > >
> > >                                       // VCPU takes a nap...
> > >         text_poke(/* first byte */)
> > >         on_each_cpu(sync)
> > >                                       <IPI>
> > >                                         ...
> > >                                       </IPI>
> > >
> > >                                       // VCPU sleeps more
> > >       bp_handler = unicorn;
> > >
> > >                                       CALL unicorn
> > >
> > > *whoops*
> > >
> > > Now, granted, that is all rather 'unlikely', but that never stopped
> > > Murphy.
> >
> > Good find, thanks Peter.
> >
> > As we discussed on IRC, we'll need to fix this from within the int3
> > exception handler by faking the call: putting a fake return address on
> > the stack (pointing to right after the call) and setting regs->ip to the
> > called function.
> 
> Can you add a comment that it will need updating when kernel CET is added?

Will do, though I get the feeling there's a lot of other (existing) code
that will also need to change for kernel CET.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-11-26 13:54 [PATCH v2 0/4] Static calls Josh Poimboeuf
                   ` (4 preceding siblings ...)
  2018-11-26 14:01 ` [PATCH v2 0/4] Static calls Josh Poimboeuf
@ 2018-11-26 20:54 ` Steven Rostedt
  2018-11-26 22:24   ` Josh Poimboeuf
  2018-12-04 23:08 ` Steven Rostedt
                   ` (2 subsequent siblings)
  8 siblings, 1 reply; 120+ messages in thread
From: Steven Rostedt @ 2018-11-26 20:54 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Peter Zijlstra, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

[-- Attachment #1: Type: text/plain, Size: 10603 bytes --]


Here's the test with the attached config (A fedora distro with
localmodconfig run against it), with also two patches to implement
tracepoints with static calls. The first makes it where a tracepoint
will call a function pointer to a single callback if there's only one
callback, or an "iterator" which iterates a list of callbacks (when
there are more than one callback associated to a tracepoint).

It adds printks() to where it enables and disables the tracepoints so
expect to see a lot of output when you enable the tracepoints. This is
to verify that it's assigning the right code.

Here's what I did.

1) I first took the config and turned off CONFIG_RETPOLINE and built
v4.20-rc4 with that. I ran this to see what the affect was without
retpolines. I booted that kernel and did the following (which is also
what I did for every kernel):

 # trace-cmd start -e all

  To get the same affect you could also do:

    # echo 1 > /sys/kernel/debug/tracing/events/enable

 # perf stat -r 10 /work/c/hackbench 50

The output was this:

No RETPOLINES:
  
# perf stat -r 10 /work/c/hackbench 50
Time: 1.351
Time: 1.414
Time: 1.319
Time: 1.277
Time: 1.280
Time: 1.305
Time: 1.294
Time: 1.342
Time: 1.319
Time: 1.288

 Performance counter stats for '/work/c/hackbench 50' (10 runs):

         10,727.44 msec task-clock                #    7.397 CPUs utilized            ( +-  0.95% )
           126,300      context-switches          # 11774.138 M/sec                   ( +- 13.80% )
            14,309      cpu-migrations            # 1333.973 M/sec                    ( +-  8.73% )
            44,073      page-faults               # 4108.652 M/sec                    ( +-  0.68% )
    39,484,799,554      cycles                    # 3680914.295 GHz                   ( +-  0.95% )
    28,470,896,143      stalled-cycles-frontend   #   72.11% frontend cycles idle     ( +-  0.95% )
    26,521,427,813      instructions              #    0.67  insn per cycle         
                                                  #    1.07  stalled cycles per insn  ( +-  0.85% )
     4,931,066,096      branches                  # 459691625.400 M/sec               ( +-  0.87% )
        19,063,801      branch-misses             #    0.39% of all branches          ( +-  2.05% )

            1.4503 +- 0.0148 seconds time elapsed  ( +-  1.02% )

Then I enabled CONFIG_RETPOLINES, built boot and ran it again:

baseline RETPOLINES:

# perf stat -r 10 /work/c/hackbench 50
Time: 1.313
Time: 1.386
Time: 1.335
Time: 1.363
Time: 1.357
Time: 1.369
Time: 1.363
Time: 1.489
Time: 1.357
Time: 1.422

 Performance counter stats for '/work/c/hackbench 50' (10 runs):

         11,162.24 msec task-clock                #    7.383 CPUs utilized            ( +-  1.11% )
           112,882      context-switches          # 10113.153 M/sec                   ( +- 15.86% )
            14,255      cpu-migrations            # 1277.103 M/sec                    ( +-  7.78% )
            43,067      page-faults               # 3858.393 M/sec                    ( +-  1.04% )
    41,076,270,559      cycles                    # 3680042.874 GHz                   ( +-  1.12% )
    29,669,137,584      stalled-cycles-frontend   #   72.23% frontend cycles idle     ( +-  1.21% )
    26,647,656,812      instructions              #    0.65  insn per cycle         
                                                  #    1.11  stalled cycles per insn  ( +-  0.81% )
     5,069,504,923      branches                  # 454179389.091 M/sec               ( +-  0.83% )
        99,135,413      branch-misses             #    1.96% of all branches          ( +-  0.87% )

            1.5120 +- 0.0133 seconds time elapsed  ( +-  0.88% )


Then I applied the first tracepoint patch to make the change to call
directly (and be able to use static calls later). And tested that.

Added direct calls for trace_events:

# perf stat -r 10 /work/c/hackbench 50
Time: 1.448
Time: 1.386
Time: 1.404
Time: 1.386
Time: 1.344
Time: 1.397
Time: 1.378
Time: 1.351
Time: 1.369
Time: 1.385

 Performance counter stats for '/work/c/hackbench 50' (10 runs):

         11,249.28 msec task-clock                #    7.382 CPUs utilized            ( +-  0.64% )
           112,058      context-switches          # 9961.721 M/sec                    ( +- 11.15% )
            15,535      cpu-migrations            # 1381.033 M/sec                    ( +- 10.34% )
            43,673      page-faults               # 3882.433 M/sec                    ( +-  1.14% )
    41,407,431,000      cycles                    # 3681020.455 GHz                   ( +-  0.63% )
    29,842,394,154      stalled-cycles-frontend   #   72.07% frontend cycles idle     ( +-  0.63% )
    26,669,867,181      instructions              #    0.64  insn per cycle         
                                                  #    1.12  stalled cycles per insn  ( +-  0.58% )
     5,085,122,641      branches                  # 452055102.392 M/sec               ( +-  0.60% )
       108,935,006      branch-misses             #    2.14% of all branches          ( +-  0.57% )

            1.5239 +- 0.0139 seconds time elapsed  ( +-  0.91% )


Then I added patch 1 and 2, and applied the second attached patch and
ran that:

With static calls:

# perf stat -r 10 /work/c/hackbench 50
Time: 1.407
Time: 1.424
Time: 1.352
Time: 1.355
Time: 1.361
Time: 1.416
Time: 1.453
Time: 1.353
Time: 1.341
Time: 1.439

 Performance counter stats for '/work/c/hackbench 50' (10 runs):

         11,293.08 msec task-clock                #    7.390 CPUs utilized            ( +-  0.93% )
           125,343      context-switches          # 11099.462 M/sec                   ( +- 11.84% )
            15,587      cpu-migrations            # 1380.272 M/sec                    ( +-  8.21% )
            43,871      page-faults               # 3884.890 M/sec                    ( +-  1.06% )
    41,567,508,330      cycles                    # 3680918.499 GHz                   ( +-  0.94% )
    29,851,271,023      stalled-cycles-frontend   #   71.81% frontend cycles idle     ( +-  0.99% )
    26,878,085,513      instructions              #    0.65  insn per cycle         
                                                  #    1.11  stalled cycles per insn  ( +-  0.72% )
     5,125,816,911      branches                  # 453905346.879 M/sec               ( +-  0.74% )
       107,643,635      branch-misses             #    2.10% of all branches          ( +-  0.71% )

            1.5282 +- 0.0135 seconds time elapsed  ( +-  0.88% )

Then I applied patch 3 and tested that:

With static call trampolines:

# perf stat -r 10 /work/c/hackbench 50
Time: 1.350
Time: 1.333
Time: 1.369
Time: 1.361
Time: 1.375
Time: 1.352
Time: 1.316
Time: 1.336
Time: 1.339
Time: 1.371

 Performance counter stats for '/work/c/hackbench 50' (10 runs):

         10,964.38 msec task-clock                #    7.392 CPUs utilized            ( +-  0.41% )
            75,986      context-switches          # 6930.527 M/sec                    ( +-  9.23% )
            12,464      cpu-migrations            # 1136.858 M/sec                    ( +-  7.93% )
            44,476      page-faults               # 4056.558 M/sec                    ( +-  1.12% )
    40,354,963,428      cycles                    # 3680712.468 GHz                   ( +-  0.42% )
    29,057,240,222      stalled-cycles-frontend   #   72.00% frontend cycles idle     ( +-  0.46% )
    26,171,883,339      instructions              #    0.65  insn per cycle         
                                                  #    1.11  stalled cycles per insn  ( +-  0.32% )
     4,978,193,830      branches                  # 454053195.523 M/sec               ( +-  0.33% )
        83,625,127      branch-misses             #    1.68% of all branches          ( +-  0.33% )

           1.48328 +- 0.00515 seconds time elapsed  ( +-  0.35% )

And finally I added patch 4 and tested that:

Full static calls:

# perf stat -r 10 /work/c/hackbench 50
Time: 1.302
Time: 1.323
Time: 1.356
Time: 1.325
Time: 1.372
Time: 1.373
Time: 1.319
Time: 1.313
Time: 1.362
Time: 1.322

 Performance counter stats for '/work/c/hackbench 50' (10 runs):

         10,865.10 msec task-clock                #    7.373 CPUs utilized            ( +-  0.62% )
            88,718      context-switches          # 8165.823 M/sec                    ( +- 10.11% )
            13,463      cpu-migrations            # 1239.125 M/sec                    ( +-  8.42% )
            44,574      page-faults               # 4102.673 M/sec                    ( +-  0.60% )
    39,991,476,585      cycles                    # 3680897.280 GHz                   ( +-  0.63% )
    28,713,229,777      stalled-cycles-frontend   #   71.80% frontend cycles idle     ( +-  0.68% )
    26,289,703,633      instructions              #    0.66  insn per cycle         
                                                  #    1.09  stalled cycles per insn  ( +-  0.44% )
     4,983,099,105      branches                  # 458654631.123 M/sec               ( +-  0.45% )
        83,719,799      branch-misses             #    1.68% of all branches          ( +-  0.44% )

           1.47364 +- 0.00706 seconds time elapsed  ( +-  0.48% )


In summary, we had this:

No RETPOLINES:
            1.4503 +- 0.0148 seconds time elapsed  ( +-  1.02% )

baseline RETPOLINES:
            1.5120 +- 0.0133 seconds time elapsed  ( +-  0.88% )

Added direct calls for trace_events:
            1.5239 +- 0.0139 seconds time elapsed  ( +-  0.91% )

With static calls:
            1.5282 +- 0.0135 seconds time elapsed  ( +-  0.88% )

With static call trampolines:
           1.48328 +- 0.00515 seconds time elapsed  ( +-  0.35% )

Full static calls:
           1.47364 +- 0.00706 seconds time elapsed  ( +-  0.48% )


Adding Retpolines caused a 1.5120 / 1.4503 = 1.0425 ( 4.25% ) slowdown

Trampolines made it into 1.48328 / 1.4503 = 1.0227 ( 2.27% ) slowdown

With full static calls 1.47364 / 1.4503 = 1.0160 ( 1.6% ) slowdown

Going from 4.25 to 1.6 isn't bad, and I think this is very much worth
the effort. I did not expect it to go to 0% as there's a lot of other
places that retpolines cause issues, but this shows that it does help
the tracing code.

I originally did the tests with the development config, which has a
bunch of debugging options enabled (hackbench usually takes over 9
seconds, not the 1.5 that was done here), and the slowdown was closer
to 9% with retpolines. If people want me to do this with that, or I can
send them the config. Or better yet, the code is here, just use your
own configs.

-- Steve

[-- Attachment #2: config-distro --]
[-- Type: application/octet-stream, Size: 134859 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86 4.20.0-rc4 Kernel Configuration
#

#
# Compiler: gcc (GCC) 8.2.1 20181011 (Red Hat 8.2.1-4)
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=80201
CONFIG_CLANG_VERSION=0
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
CONFIG_KERNEL_GZIP=y
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_POSIX_MQUEUE_SYSCTL=y
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_USELIB is not set
CONFIG_AUDIT=y
CONFIG_HAVE_ARCH_AUDITSYSCALL=y
CONFIG_AUDITSYSCALL=y
CONFIG_AUDIT_WATCH=y
CONFIG_AUDIT_TREE=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_EFFECTIVE_AFF_MASK=y
CONFIG_GENERIC_PENDING_IRQ=y
CONFIG_GENERIC_IRQ_MIGRATION=y
CONFIG_IRQ_DOMAIN=y
CONFIG_IRQ_DOMAIN_HIERARCHY=y
CONFIG_GENERIC_MSI_IRQ=y
CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y
CONFIG_GENERIC_IRQ_RESERVATION_MODE=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_ARCH_CLOCKSOURCE_DATA=y
CONFIG_ARCH_CLOCKSOURCE_INIT=y
CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
CONFIG_GENERIC_TIME_VSYSCALL=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
CONFIG_GENERIC_CMOS_UPDATE=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
# CONFIG_NO_HZ_IDLE is not set
CONFIG_NO_HZ_FULL=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# CONFIG_PREEMPT_NONE is not set
CONFIG_PREEMPT_VOLUNTARY=y
# CONFIG_PREEMPT is not set

#
# CPU/Task time and stats accounting
#
CONFIG_VIRT_CPU_ACCOUNTING=y
CONFIG_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_SCHED_AVG_IRQ=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
CONFIG_TASK_DELAY_ACCT=y
CONFIG_TASK_XACCT=y
CONFIG_TASK_IO_ACCOUNTING=y
# CONFIG_PSI is not set
CONFIG_CPU_ISOLATION=y

#
# RCU Subsystem
#
CONFIG_TREE_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TREE_SRCU=y
CONFIG_RCU_STALL_COMMON=y
CONFIG_RCU_NEED_SEGCBLIST=y
CONFIG_CONTEXT_TRACKING=y
# CONFIG_CONTEXT_TRACKING_FORCE is not set
CONFIG_RCU_NOCB_CPU=y
CONFIG_BUILD_BIN2C=y
CONFIG_IKCONFIG=m
# CONFIG_IKCONFIG_PROC is not set
CONFIG_LOG_BUF_SHIFT=18
CONFIG_LOG_CPU_MAX_BUF_SHIFT=12
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=12
CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y
CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y
CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y
CONFIG_ARCH_SUPPORTS_INT128=y
CONFIG_NUMA_BALANCING=y
CONFIG_NUMA_BALANCING_DEFAULT_ENABLED=y
CONFIG_CGROUPS=y
CONFIG_PAGE_COUNTER=y
CONFIG_MEMCG=y
CONFIG_MEMCG_SWAP=y
CONFIG_MEMCG_SWAP_ENABLED=y
CONFIG_MEMCG_KMEM=y
CONFIG_BLK_CGROUP=y
# CONFIG_DEBUG_BLK_CGROUP is not set
CONFIG_CGROUP_WRITEBACK=y
CONFIG_CGROUP_SCHED=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_CFS_BANDWIDTH=y
# CONFIG_RT_GROUP_SCHED is not set
CONFIG_CGROUP_PIDS=y
# CONFIG_CGROUP_RDMA is not set
CONFIG_CGROUP_FREEZER=y
CONFIG_CGROUP_HUGETLB=y
CONFIG_CPUSETS=y
CONFIG_PROC_PID_CPUSET=y
CONFIG_CGROUP_DEVICE=y
CONFIG_CGROUP_CPUACCT=y
CONFIG_CGROUP_PERF=y
CONFIG_CGROUP_BPF=y
# CONFIG_CGROUP_DEBUG is not set
CONFIG_SOCK_CGROUP_DATA=y
CONFIG_NAMESPACES=y
CONFIG_UTS_NS=y
CONFIG_IPC_NS=y
CONFIG_USER_NS=y
CONFIG_PID_NS=y
CONFIG_NET_NS=y
# CONFIG_CHECKPOINT_RESTORE is not set
CONFIG_SCHED_AUTOGROUP=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
CONFIG_RD_BZIP2=y
CONFIG_RD_LZMA=y
CONFIG_RD_XZ=y
CONFIG_RD_LZO=y
CONFIG_RD_LZ4=y
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_SYSCTL_EXCEPTION_TRACE=y
CONFIG_HAVE_PCSPKR_PLATFORM=y
CONFIG_BPF=y
# CONFIG_EXPERT is not set
CONFIG_UID16=y
CONFIG_MULTIUSER=y
CONFIG_SGETMASK_SYSCALL=y
CONFIG_SYSFS_SYSCALL=y
CONFIG_FHANDLE=y
CONFIG_POSIX_TIMERS=y
CONFIG_PRINTK=y
CONFIG_PRINTK_NMI=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_PCSPKR_PLATFORM=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_FUTEX_PI=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
CONFIG_ADVISE_SYSCALLS=y
CONFIG_MEMBARRIER=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_ABSOLUTE_PERCPU=y
CONFIG_KALLSYMS_BASE_RELATIVE=y
CONFIG_BPF_SYSCALL=y
# CONFIG_BPF_JIT_ALWAYS_ON is not set
CONFIG_USERFAULTFD=y
CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y
CONFIG_RSEQ=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
# CONFIG_DEBUG_PERF_USE_VMALLOC is not set
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
CONFIG_SLAB_MERGE_DEFAULT=y
CONFIG_SLAB_FREELIST_RANDOM=y
# CONFIG_SLAB_FREELIST_HARDENED is not set
CONFIG_SLUB_CPU_PARTIAL=y
CONFIG_SYSTEM_DATA_VERIFICATION=y
CONFIG_PROFILING=y
CONFIG_TRACEPOINTS=y
CONFIG_64BIT=y
CONFIG_X86_64=y
CONFIG_X86=y
CONFIG_INSTRUCTION_DECODER=y
CONFIG_OUTPUT_FORMAT="elf64-x86-64"
CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_MMU=y
CONFIG_ARCH_MMAP_RND_BITS_MIN=28
CONFIG_ARCH_MMAP_RND_BITS_MAX=32
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_ARCH_HAS_CPU_RELAX=y
CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
CONFIG_ARCH_HAS_FILTER_PGPROT=y
CONFIG_HAVE_SETUP_PER_CPU_AREA=y
CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
CONFIG_ARCH_HIBERNATION_POSSIBLE=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_ZONE_DMA32=y
CONFIG_AUDIT_ARCH=y
CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
CONFIG_HAVE_INTEL_TXT=y
CONFIG_X86_64_SMP=y
CONFIG_ARCH_SUPPORTS_UPROBES=y
CONFIG_FIX_EARLYCON_MEM=y
CONFIG_PGTABLE_LEVELS=4
CONFIG_CC_HAS_SANE_STACKPROTECTOR=y

#
# Processor type and features
#
CONFIG_ZONE_DMA=y
CONFIG_SMP=y
CONFIG_X86_FEATURE_NAMES=y
CONFIG_X86_X2APIC=y
CONFIG_X86_MPPARSE=y
# CONFIG_GOLDFISH is not set
CONFIG_RETPOLINE=y
# CONFIG_INTEL_RDT is not set
CONFIG_X86_EXTENDED_PLATFORM=y
CONFIG_X86_NUMACHIP=y
# CONFIG_X86_VSMP is not set
CONFIG_X86_UV=y
# CONFIG_X86_GOLDFISH is not set
# CONFIG_X86_INTEL_MID is not set
CONFIG_X86_INTEL_LPSS=y
CONFIG_X86_AMD_PLATFORM_DEVICE=y
CONFIG_IOSF_MBI=y
# CONFIG_IOSF_MBI_DEBUG is not set
CONFIG_X86_SUPPORTS_MEMORY_FAILURE=y
CONFIG_SCHED_OMIT_FRAME_POINTER=y
CONFIG_HYPERVISOR_GUEST=y
CONFIG_PARAVIRT=y
CONFIG_PARAVIRT_XXL=y
# CONFIG_PARAVIRT_DEBUG is not set
# CONFIG_PARAVIRT_SPINLOCKS is not set
CONFIG_XEN=y
CONFIG_XEN_PV=y
CONFIG_XEN_PV_SMP=y
CONFIG_XEN_DOM0=y
CONFIG_XEN_PVHVM=y
CONFIG_XEN_PVHVM_SMP=y
CONFIG_XEN_512GB=y
CONFIG_XEN_SAVE_RESTORE=y
CONFIG_XEN_DEBUG_FS=y
CONFIG_XEN_PVH=y
CONFIG_KVM_GUEST=y
# CONFIG_KVM_DEBUG_FS is not set
CONFIG_PARAVIRT_TIME_ACCOUNTING=y
CONFIG_PARAVIRT_CLOCK=y
# CONFIG_JAILHOUSE_GUEST is not set
# CONFIG_MK8 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_MATOM is not set
CONFIG_GENERIC_CPU=y
CONFIG_X86_INTERNODE_CACHE_SHIFT=6
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_TSC=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_CMOV=y
CONFIG_X86_MINIMUM_CPU_FAMILY=64
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_CPU_SUP_INTEL=y
CONFIG_CPU_SUP_AMD=y
CONFIG_CPU_SUP_HYGON=y
CONFIG_CPU_SUP_CENTAUR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_DMI=y
CONFIG_GART_IOMMU=y
# CONFIG_CALGARY_IOMMU is not set
# CONFIG_MAXSMP is not set
CONFIG_NR_CPUS_RANGE_BEGIN=2
CONFIG_NR_CPUS_RANGE_END=512
CONFIG_NR_CPUS_DEFAULT=64
CONFIG_NR_CPUS=128
CONFIG_SCHED_SMT=y
CONFIG_SCHED_MC=y
CONFIG_SCHED_MC_PRIO=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_REROUTE_FOR_BROKEN_BOOT_IRQS=y
CONFIG_X86_MCE=y
CONFIG_X86_MCELOG_LEGACY=y
CONFIG_X86_MCE_INTEL=y
CONFIG_X86_MCE_AMD=y
CONFIG_X86_MCE_THRESHOLD=y
# CONFIG_X86_MCE_INJECT is not set
CONFIG_X86_THERMAL_VECTOR=y

#
# Performance monitoring
#
# CONFIG_PERF_EVENTS_INTEL_UNCORE is not set
# CONFIG_PERF_EVENTS_INTEL_RAPL is not set
# CONFIG_PERF_EVENTS_INTEL_CSTATE is not set
# CONFIG_PERF_EVENTS_AMD_POWER is not set
CONFIG_X86_16BIT=y
CONFIG_X86_ESPFIX64=y
CONFIG_X86_VSYSCALL_EMULATION=y
# CONFIG_I8K is not set
CONFIG_MICROCODE=y
CONFIG_MICROCODE_INTEL=y
CONFIG_MICROCODE_AMD=y
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=y
CONFIG_X86_CPUID=y
# CONFIG_X86_5LEVEL is not set
CONFIG_X86_DIRECT_GBPAGES=y
# CONFIG_X86_CPA_STATISTICS is not set
CONFIG_ARCH_HAS_MEM_ENCRYPT=y
# CONFIG_AMD_MEM_ENCRYPT is not set
CONFIG_NUMA=y
CONFIG_AMD_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_NODES_SPAN_OTHER_NODES=y
# CONFIG_NUMA_EMU is not set
CONFIG_NODES_SHIFT=10
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_DEFAULT=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
# CONFIG_ARCH_MEMORY_PROBE is not set
CONFIG_ARCH_PROC_KCORE_TEXT=y
CONFIG_ILLEGAL_POINTER_VALUE=0xdead000000000000
# CONFIG_X86_PMEM_LEGACY is not set
CONFIG_X86_CHECK_BIOS_CORRUPTION=y
# CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK is not set
CONFIG_X86_RESERVE_LOW=64
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
CONFIG_X86_PAT=y
CONFIG_ARCH_USES_PG_UNCACHED=y
CONFIG_ARCH_RANDOM=y
CONFIG_X86_SMAP=y
CONFIG_X86_INTEL_UMIP=y
CONFIG_X86_INTEL_MPX=y
CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_EFI_MIXED=y
CONFIG_SECCOMP=y
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
CONFIG_HZ_1000=y
CONFIG_HZ=1000
CONFIG_SCHED_HRTICK=y
CONFIG_KEXEC=y
CONFIG_KEXEC_FILE=y
CONFIG_ARCH_HAS_KEXEC_PURGATORY=y
# CONFIG_KEXEC_VERIFY_SIG is not set
CONFIG_CRASH_DUMP=y
CONFIG_KEXEC_JUMP=y
CONFIG_PHYSICAL_START=0x1000000
CONFIG_RELOCATABLE=y
CONFIG_RANDOMIZE_BASE=y
CONFIG_X86_NEED_RELOCS=y
CONFIG_PHYSICAL_ALIGN=0x1000000
CONFIG_DYNAMIC_MEMORY_LAYOUT=y
CONFIG_RANDOMIZE_MEMORY=y
CONFIG_RANDOMIZE_MEMORY_PHYSICAL_PADDING=0xa
CONFIG_HOTPLUG_CPU=y
# CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set
# CONFIG_DEBUG_HOTPLUG_CPU0 is not set
# CONFIG_COMPAT_VDSO is not set
CONFIG_LEGACY_VSYSCALL_EMULATE=y
# CONFIG_LEGACY_VSYSCALL_NONE is not set
# CONFIG_CMDLINE_BOOL is not set
CONFIG_MODIFY_LDT_SYSCALL=y
CONFIG_HAVE_LIVEPATCH=y
# CONFIG_LIVEPATCH is not set
CONFIG_ARCH_HAS_ADD_PAGES=y
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
CONFIG_ARCH_ENABLE_MEMORY_HOTREMOVE=y
CONFIG_USE_PERCPU_NUMA_NODE_ID=y
CONFIG_ARCH_ENABLE_SPLIT_PMD_PTLOCK=y
CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION=y
CONFIG_ARCH_ENABLE_THP_MIGRATION=y

#
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
CONFIG_PM_TEST_SUSPEND=y
CONFIG_PM_SLEEP_DEBUG=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_ARCH_SUPPORTS_ACPI=y
CONFIG_ACPI=y
CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
# CONFIG_ACPI_DEBUGGER is not set
CONFIG_ACPI_SPCR_TABLE=y
CONFIG_ACPI_LPIT=y
CONFIG_ACPI_SLEEP=y
# CONFIG_ACPI_PROCFS_POWER is not set
CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=m
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_TAD is not set
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_CPU_FREQ_PSS=y
CONFIG_ACPI_PROCESSOR_CSTATE=y
CONFIG_ACPI_PROCESSOR_IDLE=y
CONFIG_ACPI_CPPC_LIB=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
CONFIG_ACPI_THERMAL=y
CONFIG_ACPI_NUMA=y
CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_TABLE_UPGRADE=y
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_PCI_SLOT=y
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_HOTPLUG_MEMORY=y
CONFIG_ACPI_HOTPLUG_IOAPIC=y
# CONFIG_ACPI_SBS is not set
CONFIG_ACPI_HED=y
# CONFIG_ACPI_CUSTOM_METHOD is not set
CONFIG_ACPI_BGRT=y
# CONFIG_ACPI_NFIT is not set
CONFIG_HAVE_ACPI_APEI=y
CONFIG_HAVE_ACPI_APEI_NMI=y
CONFIG_ACPI_APEI=y
CONFIG_ACPI_APEI_GHES=y
CONFIG_ACPI_APEI_PCIEAER=y
CONFIG_ACPI_APEI_MEMORY_FAILURE=y
# CONFIG_ACPI_APEI_EINJ is not set
# CONFIG_ACPI_APEI_ERST_DEBUG is not set
# CONFIG_DPTF_POWER is not set
# CONFIG_ACPI_EXTLOG is not set
CONFIG_PMIC_OPREGION=y
CONFIG_CRC_PMIC_OPREGION=y
CONFIG_XPOWER_PMIC_OPREGION=y
CONFIG_CHT_WC_PMIC_OPREGION=y
# CONFIG_ACPI_CONFIGFS is not set
CONFIG_X86_PM_TIMER=y
CONFIG_SFI=y

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_GOV_ATTR_SET=y
CONFIG_CPU_FREQ_GOV_COMMON=y
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_SCHEDUTIL is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
CONFIG_CPU_FREQ_GOV_SCHEDUTIL=y

#
# CPU frequency scaling drivers
#
CONFIG_X86_INTEL_PSTATE=y
# CONFIG_X86_PCC_CPUFREQ is not set
# CONFIG_X86_ACPI_CPUFREQ is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_P4_CLOCKMOD is not set

#
# shared options
#

#
# CPU Idle
#
CONFIG_CPU_IDLE=y
CONFIG_CPU_IDLE_GOV_LADDER=y
CONFIG_CPU_IDLE_GOV_MENU=y
CONFIG_INTEL_IDLE=y

#
# Bus options (PCI etc.)
#
CONFIG_PCI=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_XEN=y
CONFIG_PCI_DOMAINS=y
CONFIG_MMCONF_FAM10H=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=y
CONFIG_PCIEAER=y
# CONFIG_PCIEAER_INJECT is not set
CONFIG_PCIE_ECRC=y
CONFIG_PCIEASPM=y
# CONFIG_PCIEASPM_DEBUG is not set
CONFIG_PCIEASPM_DEFAULT=y
# CONFIG_PCIEASPM_POWERSAVE is not set
# CONFIG_PCIEASPM_POWER_SUPERSAVE is not set
# CONFIG_PCIEASPM_PERFORMANCE is not set
CONFIG_PCIE_PME=y
CONFIG_PCIE_DPC=y
CONFIG_PCIE_PTM=y
CONFIG_PCI_MSI=y
CONFIG_PCI_MSI_IRQ_DOMAIN=y
CONFIG_PCI_QUIRKS=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_PCI_REALLOC_ENABLE_AUTO is not set
CONFIG_PCI_STUB=y
# CONFIG_PCI_PF_STUB is not set
# CONFIG_XEN_PCIDEV_FRONTEND is not set
CONFIG_PCI_ATS=y
CONFIG_PCI_LOCKLESS_CONFIG=y
CONFIG_PCI_IOV=y
CONFIG_PCI_PRI=y
CONFIG_PCI_PASID=y
# CONFIG_PCI_P2PDMA is not set
CONFIG_PCI_LABEL=y
CONFIG_HOTPLUG_PCI=y
CONFIG_HOTPLUG_PCI_ACPI=y
# CONFIG_HOTPLUG_PCI_ACPI_IBM is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set

#
# PCI controller drivers
#

#
# Cadence PCIe controllers support
#
# CONFIG_VMD is not set

#
# DesignWare PCI Core Support
#
# CONFIG_PCIE_DW_PLAT_HOST is not set

#
# PCI Endpoint
#
# CONFIG_PCI_ENDPOINT is not set

#
# PCI switch controller drivers
#
# CONFIG_PCI_SW_SWITCHTEC is not set
CONFIG_ISA_DMA_API=y
CONFIG_AMD_NB=y
CONFIG_PCCARD=y
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_CARDBUS=y

#
# PC-card bridges
#
# CONFIG_YENTA is not set
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
# CONFIG_RAPIDIO is not set
# CONFIG_X86_SYSFB is not set

#
# Binary Emulations
#
CONFIG_IA32_EMULATION=y
# CONFIG_IA32_AOUT is not set
# CONFIG_X86_X32 is not set
CONFIG_COMPAT_32=y
CONFIG_COMPAT=y
CONFIG_COMPAT_FOR_U64_ALIGNMENT=y
CONFIG_SYSVIPC_COMPAT=y
CONFIG_X86_DEV_DMA_OPS=y
CONFIG_HAVE_GENERIC_GUP=y

#
# Firmware Drivers
#
# CONFIG_EDD is not set
CONFIG_FIRMWARE_MEMMAP=y
CONFIG_DMIID=y
CONFIG_DMI_SYSFS=y
CONFIG_DMI_SCAN_MACHINE_NON_EFI_FALLBACK=y
CONFIG_ISCSI_IBFT_FIND=y
# CONFIG_ISCSI_IBFT is not set
# CONFIG_FW_CFG_SYSFS is not set
# CONFIG_GOOGLE_FIRMWARE is not set

#
# EFI (Extensible Firmware Interface) Support
#
# CONFIG_EFI_VARS is not set
CONFIG_EFI_ESRT=y
CONFIG_EFI_RUNTIME_MAP=y
# CONFIG_EFI_FAKE_MEMMAP is not set
CONFIG_EFI_RUNTIME_WRAPPERS=y
# CONFIG_EFI_CAPSULE_LOADER is not set
# CONFIG_EFI_TEST is not set
CONFIG_APPLE_PROPERTIES=y
# CONFIG_RESET_ATTACK_MITIGATION is not set
CONFIG_UEFI_CPER=y
CONFIG_UEFI_CPER_X86=y
CONFIG_EFI_DEV_PATH_PARSER=y

#
# Tegra firmware driver
#
CONFIG_HAVE_KVM=y
CONFIG_HAVE_KVM_IRQCHIP=y
CONFIG_HAVE_KVM_IRQFD=y
CONFIG_HAVE_KVM_IRQ_ROUTING=y
CONFIG_HAVE_KVM_EVENTFD=y
CONFIG_KVM_MMIO=y
CONFIG_KVM_ASYNC_PF=y
CONFIG_HAVE_KVM_MSI=y
CONFIG_HAVE_KVM_CPU_RELAX_INTERCEPT=y
CONFIG_KVM_VFIO=y
CONFIG_KVM_GENERIC_DIRTYLOG_READ_PROTECT=y
CONFIG_KVM_COMPAT=y
CONFIG_HAVE_KVM_IRQ_BYPASS=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
# CONFIG_KVM_AMD is not set
CONFIG_KVM_MMU_AUDIT=y
# CONFIG_VHOST_NET is not set
# CONFIG_VHOST_CROSS_ENDIAN_LEGACY is not set

#
# General architecture-dependent options
#
CONFIG_CRASH_CORE=y
CONFIG_KEXEC_CORE=y
CONFIG_HOTPLUG_SMT=y
# CONFIG_OPROFILE is not set
CONFIG_HAVE_OPROFILE=y
CONFIG_OPROFILE_NMI_TIMER=y
CONFIG_KPROBES=y
CONFIG_JUMP_LABEL=y
# CONFIG_STATIC_KEYS_SELFTEST is not set
CONFIG_OPTPROBES=y
CONFIG_KPROBES_ON_FTRACE=y
CONFIG_UPROBES=y
CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y
CONFIG_ARCH_USE_BUILTIN_BSWAP=y
CONFIG_KRETPROBES=y
CONFIG_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_IOREMAP_PROT=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_OPTPROBES=y
CONFIG_HAVE_KPROBES_ON_FTRACE=y
CONFIG_HAVE_FUNCTION_ERROR_INJECTION=y
CONFIG_HAVE_NMI=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_ARCH_HAS_FORTIFY_SOURCE=y
CONFIG_ARCH_HAS_SET_MEMORY=y
CONFIG_HAVE_ARCH_THREAD_STRUCT_WHITELIST=y
CONFIG_ARCH_WANTS_DYNAMIC_TASK_STRUCT=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_RSEQ=y
CONFIG_HAVE_FUNCTION_ARG_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_MIXED_BREAKPOINTS_REGS=y
CONFIG_HAVE_USER_RETURN_NOTIFIER=y
CONFIG_HAVE_PERF_EVENTS_NMI=y
CONFIG_HAVE_HARDLOCKUP_DETECTOR_PERF=y
CONFIG_HAVE_PERF_REGS=y
CONFIG_HAVE_PERF_USER_STACK_DUMP=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_HAVE_ARCH_JUMP_LABEL_RELATIVE=y
CONFIG_HAVE_RCU_TABLE_FREE=y
CONFIG_HAVE_RCU_TABLE_INVALIDATE=y
CONFIG_ARCH_HAVE_NMI_SAFE_CMPXCHG=y
CONFIG_HAVE_ALIGNED_STRUCT_PAGE=y
CONFIG_HAVE_CMPXCHG_LOCAL=y
CONFIG_HAVE_CMPXCHG_DOUBLE=y
CONFIG_ARCH_WANT_COMPAT_IPC_PARSE_VERSION=y
CONFIG_ARCH_WANT_OLD_COMPAT_IPC=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_SECCOMP_FILTER=y
CONFIG_HAVE_ARCH_STACKLEAK=y
CONFIG_HAVE_STACKPROTECTOR=y
CONFIG_CC_HAS_STACKPROTECTOR_NONE=y
CONFIG_STACKPROTECTOR=y
CONFIG_STACKPROTECTOR_STRONG=y
CONFIG_HAVE_ARCH_WITHIN_STACK_FRAMES=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_VIRT_CPU_ACCOUNTING_GEN=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y
CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE_PUD=y
CONFIG_HAVE_ARCH_HUGE_VMAP=y
CONFIG_HAVE_ARCH_SOFT_DIRTY=y
CONFIG_HAVE_MOD_ARCH_SPECIFIC=y
CONFIG_MODULES_USE_ELF_RELA=y
CONFIG_HAVE_IRQ_EXIT_ON_IRQ_STACK=y
CONFIG_ARCH_HAS_ELF_RANDOMIZE=y
CONFIG_HAVE_ARCH_MMAP_RND_BITS=y
CONFIG_HAVE_EXIT_THREAD=y
CONFIG_ARCH_MMAP_RND_BITS=28
CONFIG_HAVE_ARCH_MMAP_RND_COMPAT_BITS=y
CONFIG_ARCH_MMAP_RND_COMPAT_BITS=8
CONFIG_HAVE_ARCH_COMPAT_MMAP_BASES=y
CONFIG_HAVE_COPY_THREAD_TLS=y
CONFIG_HAVE_STACK_VALIDATION=y
CONFIG_HAVE_RELIABLE_STACKTRACE=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_COMPAT_OLD_SIGACTION=y
CONFIG_COMPAT_32BIT_TIME=y
CONFIG_HAVE_ARCH_VMAP_STACK=y
CONFIG_VMAP_STACK=y
CONFIG_ARCH_HAS_STRICT_KERNEL_RWX=y
CONFIG_STRICT_KERNEL_RWX=y
CONFIG_ARCH_HAS_STRICT_MODULE_RWX=y
CONFIG_STRICT_MODULE_RWX=y
CONFIG_ARCH_HAS_REFCOUNT=y
# CONFIG_REFCOUNT_FULL is not set
CONFIG_HAVE_ARCH_PREL32_RELOCATIONS=y
CONFIG_HAVE_STATIC_CALL_INLINE=y
CONFIG_HAVE_STATIC_CALL=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_ARCH_HAS_GCOV_PROFILE_ALL=y
CONFIG_PLUGIN_HOSTCC=""
CONFIG_HAVE_GCC_PLUGINS=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_MODULE_SIG=y
# CONFIG_MODULE_SIG_FORCE is not set
CONFIG_MODULE_SIG_ALL=y
# CONFIG_MODULE_SIG_SHA1 is not set
# CONFIG_MODULE_SIG_SHA224 is not set
CONFIG_MODULE_SIG_SHA256=y
# CONFIG_MODULE_SIG_SHA384 is not set
# CONFIG_MODULE_SIG_SHA512 is not set
CONFIG_MODULE_SIG_HASH="sha256"
# CONFIG_MODULE_COMPRESS is not set
CONFIG_MODULES_TREE_LOOKUP=y
CONFIG_BLOCK=y
CONFIG_BLK_SCSI_REQUEST=y
CONFIG_BLK_DEV_BSG=y
CONFIG_BLK_DEV_BSGLIB=y
CONFIG_BLK_DEV_INTEGRITY=y
CONFIG_BLK_DEV_ZONED=y
CONFIG_BLK_DEV_THROTTLING=y
# CONFIG_BLK_DEV_THROTTLING_LOW is not set
# CONFIG_BLK_CMDLINE_PARSER is not set
CONFIG_BLK_WBT=y
# CONFIG_BLK_CGROUP_IOLATENCY is not set
# CONFIG_BLK_WBT_SQ is not set
CONFIG_BLK_WBT_MQ=y
CONFIG_BLK_DEBUG_FS=y
CONFIG_BLK_DEBUG_FS_ZONED=y
CONFIG_BLK_SED_OPAL=y

#
# Partition Types
#
CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
CONFIG_AIX_PARTITION=y
CONFIG_OSF_PARTITION=y
CONFIG_AMIGA_PARTITION=y
# CONFIG_ATARI_PARTITION is not set
CONFIG_MAC_PARTITION=y
CONFIG_MSDOS_PARTITION=y
CONFIG_BSD_DISKLABEL=y
CONFIG_MINIX_SUBPARTITION=y
CONFIG_SOLARIS_X86_PARTITION=y
CONFIG_UNIXWARE_DISKLABEL=y
CONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
CONFIG_SGI_PARTITION=y
# CONFIG_ULTRIX_PARTITION is not set
CONFIG_SUN_PARTITION=y
CONFIG_KARMA_PARTITION=y
CONFIG_EFI_PARTITION=y
# CONFIG_SYSV68_PARTITION is not set
# CONFIG_CMDLINE_PARTITION is not set
CONFIG_BLOCK_COMPAT=y
CONFIG_BLK_MQ_PCI=y
CONFIG_BLK_MQ_VIRTIO=y
CONFIG_BLK_PM=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_CFQ_GROUP_IOSCHED=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_MQ_IOSCHED_DEADLINE=y
# CONFIG_MQ_IOSCHED_KYBER is not set
# CONFIG_IOSCHED_BFQ is not set
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_ASN1=y
CONFIG_INLINE_SPIN_UNLOCK_IRQ=y
CONFIG_INLINE_READ_UNLOCK=y
CONFIG_INLINE_READ_UNLOCK_IRQ=y
CONFIG_INLINE_WRITE_UNLOCK=y
CONFIG_INLINE_WRITE_UNLOCK_IRQ=y
CONFIG_ARCH_SUPPORTS_ATOMIC_RMW=y
CONFIG_MUTEX_SPIN_ON_OWNER=y
CONFIG_RWSEM_SPIN_ON_OWNER=y
CONFIG_LOCK_SPIN_ON_OWNER=y
CONFIG_ARCH_USE_QUEUED_SPINLOCKS=y
CONFIG_QUEUED_SPINLOCKS=y
CONFIG_ARCH_USE_QUEUED_RWLOCKS=y
CONFIG_QUEUED_RWLOCKS=y
CONFIG_ARCH_HAS_SYNC_CORE_BEFORE_USERMODE=y
CONFIG_ARCH_HAS_SYSCALL_WRAPPER=y
CONFIG_FREEZER=y

#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_COMPAT_BINFMT_ELF=y
CONFIG_ELFCORE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_BINFMT_MISC is not set
CONFIG_COREDUMP=y

#
# Memory Management options
#
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_SPARSEMEM_MANUAL=y
CONFIG_SPARSEMEM=y
CONFIG_NEED_MULTIPLE_NODES=y
CONFIG_HAVE_MEMORY_PRESENT=y
CONFIG_SPARSEMEM_EXTREME=y
CONFIG_SPARSEMEM_VMEMMAP_ENABLE=y
CONFIG_SPARSEMEM_VMEMMAP=y
CONFIG_HAVE_MEMBLOCK_NODE_MAP=y
CONFIG_ARCH_DISCARD_MEMBLOCK=y
CONFIG_MEMORY_ISOLATION=y
CONFIG_HAVE_BOOTMEM_INFO_NODE=y
CONFIG_MEMORY_HOTPLUG=y
CONFIG_MEMORY_HOTPLUG_SPARSE=y
CONFIG_MEMORY_HOTPLUG_DEFAULT_ONLINE=y
CONFIG_MEMORY_HOTREMOVE=y
CONFIG_SPLIT_PTLOCK_CPUS=4
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
CONFIG_PHYS_ADDR_T_64BIT=y
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
CONFIG_MMU_NOTIFIER=y
CONFIG_KSM=y
CONFIG_DEFAULT_MMAP_MIN_ADDR=65536
CONFIG_ARCH_SUPPORTS_MEMORY_FAILURE=y
CONFIG_MEMORY_FAILURE=y
# CONFIG_HWPOISON_INJECT is not set
CONFIG_TRANSPARENT_HUGEPAGE=y
# CONFIG_TRANSPARENT_HUGEPAGE_ALWAYS is not set
CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y
CONFIG_ARCH_WANTS_THP_SWAP=y
CONFIG_THP_SWAP=y
CONFIG_TRANSPARENT_HUGE_PAGECACHE=y
CONFIG_CLEANCACHE=y
CONFIG_FRONTSWAP=y
CONFIG_CMA=y
# CONFIG_CMA_DEBUG is not set
# CONFIG_CMA_DEBUGFS is not set
CONFIG_CMA_AREAS=7
CONFIG_ZSWAP=y
CONFIG_ZPOOL=y
CONFIG_ZBUD=y
CONFIG_Z3FOLD=y
CONFIG_ZSMALLOC=y
# CONFIG_PGTABLE_MAPPING is not set
# CONFIG_ZSMALLOC_STAT is not set
CONFIG_GENERIC_EARLY_IOREMAP=y
# CONFIG_DEFERRED_STRUCT_PAGE_INIT is not set
# CONFIG_IDLE_PAGE_TRACKING is not set
CONFIG_ARCH_HAS_ZONE_DEVICE=y
CONFIG_ZONE_DEVICE=y
CONFIG_ARCH_HAS_HMM=y
CONFIG_DEV_PAGEMAP_OPS=y
# CONFIG_HMM_MIRROR is not set
# CONFIG_DEVICE_PRIVATE is not set
# CONFIG_DEVICE_PUBLIC is not set
CONFIG_ARCH_USES_HIGH_VMA_FLAGS=y
CONFIG_ARCH_HAS_PKEYS=y
# CONFIG_PERCPU_STATS is not set
# CONFIG_GUP_BENCHMARK is not set
CONFIG_ARCH_HAS_PTE_SPECIAL=y
CONFIG_NET=y
CONFIG_NET_INGRESS=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
# CONFIG_TLS is not set
CONFIG_XFRM=y
CONFIG_XFRM_ALGO=y
CONFIG_XFRM_USER=y
# CONFIG_XFRM_INTERFACE is not set
CONFIG_XFRM_SUB_POLICY=y
CONFIG_XFRM_MIGRATE=y
CONFIG_XFRM_STATISTICS=y
# CONFIG_NET_KEY is not set
# CONFIG_XDP_SOCKETS is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_IP_FIB_TRIE_STATS=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
CONFIG_IP_MROUTE_COMMON=y
CONFIG_IP_MROUTE=y
CONFIG_IP_MROUTE_MULTIPLE_TABLES=y
CONFIG_IP_PIMSM_V1=y
CONFIG_IP_PIMSM_V2=y
CONFIG_SYN_COOKIES=y
# CONFIG_NET_FOU is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_DIAG is not set
CONFIG_TCP_CONG_ADVANCED=y
# CONFIG_TCP_CONG_BIC is not set
CONFIG_TCP_CONG_CUBIC=y
# CONFIG_TCP_CONG_WESTWOOD is not set
# CONFIG_TCP_CONG_HTCP is not set
# CONFIG_TCP_CONG_HSTCP is not set
# CONFIG_TCP_CONG_HYBLA is not set
# CONFIG_TCP_CONG_VEGAS is not set
# CONFIG_TCP_CONG_NV is not set
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_TCP_CONG_YEAH is not set
# CONFIG_TCP_CONG_ILLINOIS is not set
# CONFIG_TCP_CONG_DCTCP is not set
# CONFIG_TCP_CONG_CDG is not set
# CONFIG_TCP_CONG_BBR is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
CONFIG_TCP_MD5SIG=y
CONFIG_IPV6=y
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
CONFIG_IPV6_OPTIMISTIC_DAD=y
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
CONFIG_IPV6_MIP6=y
# CONFIG_IPV6_ILA is not set
# CONFIG_INET6_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET6_XFRM_MODE_TUNNEL is not set
# CONFIG_INET6_XFRM_MODE_BEET is not set
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
# CONFIG_IPV6_SIT is not set
# CONFIG_IPV6_TUNNEL is not set
CONFIG_IPV6_MULTIPLE_TABLES=y
CONFIG_IPV6_SUBTREES=y
CONFIG_IPV6_MROUTE=y
CONFIG_IPV6_MROUTE_MULTIPLE_TABLES=y
CONFIG_IPV6_PIMSM_V2=y
CONFIG_IPV6_SEG6_LWTUNNEL=y
CONFIG_IPV6_SEG6_HMAC=y
CONFIG_IPV6_SEG6_BPF=y
CONFIG_NETLABEL=y
CONFIG_NETWORK_SECMARK=y
CONFIG_NET_PTP_CLASSIFY=y
CONFIG_NETWORK_PHY_TIMESTAMPING=y
CONFIG_NETFILTER=y
CONFIG_NETFILTER_ADVANCED=y

#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_INGRESS=y
# CONFIG_NETFILTER_NETLINK_ACCT is not set
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NETFILTER_NETLINK_OSF is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NF_LOG_NETDEV is not set
# CONFIG_NF_TABLES is not set
CONFIG_NETFILTER_XTABLES=y

#
# Xtables combined modules
#
# CONFIG_NETFILTER_XT_MARK is not set

#
# Xtables targets
#
# CONFIG_NETFILTER_XT_TARGET_AUDIT is not set
# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set
# CONFIG_NETFILTER_XT_TARGET_HMARK is not set
# CONFIG_NETFILTER_XT_TARGET_IDLETIMER is not set
# CONFIG_NETFILTER_XT_TARGET_LED is not set
# CONFIG_NETFILTER_XT_TARGET_LOG is not set
# CONFIG_NETFILTER_XT_TARGET_MARK is not set
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set
# CONFIG_NETFILTER_XT_TARGET_RATEEST is not set
# CONFIG_NETFILTER_XT_TARGET_TEE is not set
# CONFIG_NETFILTER_XT_TARGET_SECMARK is not set
# CONFIG_NETFILTER_XT_TARGET_TCPMSS is not set

#
# Xtables matches
#
# CONFIG_NETFILTER_XT_MATCH_ADDRTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_BPF is not set
# CONFIG_NETFILTER_XT_MATCH_CGROUP is not set
# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set
# CONFIG_NETFILTER_XT_MATCH_CPU is not set
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DEVGROUP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ECN is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_HL is not set
# CONFIG_NETFILTER_XT_MATCH_IPCOMP is not set
# CONFIG_NETFILTER_XT_MATCH_IPRANGE is not set
# CONFIG_NETFILTER_XT_MATCH_L2TP is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_MAC is not set
# CONFIG_NETFILTER_XT_MATCH_MARK is not set
# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set
# CONFIG_NETFILTER_XT_MATCH_NFACCT is not set
# CONFIG_NETFILTER_XT_MATCH_OSF is not set
# CONFIG_NETFILTER_XT_MATCH_OWNER is not set
# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
# CONFIG_NETFILTER_XT_MATCH_RATEEST is not set
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
# CONFIG_NETFILTER_XT_MATCH_RECENT is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
# CONFIG_NETFILTER_XT_MATCH_SOCKET is not set
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
# CONFIG_NETFILTER_XT_MATCH_STRING is not set
# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_IP_SET is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
# CONFIG_NF_SOCKET_IPV4 is not set
# CONFIG_NF_TPROXY_IPV4 is not set
# CONFIG_NF_DUP_IPV4 is not set
# CONFIG_NF_LOG_ARP is not set
# CONFIG_NF_LOG_IPV4 is not set
CONFIG_NF_REJECT_IPV4=y
CONFIG_IP_NF_IPTABLES=y
# CONFIG_IP_NF_MATCH_AH is not set
# CONFIG_IP_NF_MATCH_ECN is not set
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
# CONFIG_IP_NF_MANGLE is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_SECURITY is not set
# CONFIG_IP_NF_ARPTABLES is not set

#
# IPv6: Netfilter Configuration
#
# CONFIG_NF_SOCKET_IPV6 is not set
# CONFIG_NF_TPROXY_IPV6 is not set
# CONFIG_NF_DUP_IPV6 is not set
# CONFIG_NF_REJECT_IPV6 is not set
# CONFIG_NF_LOG_IPV6 is not set
CONFIG_IP6_NF_IPTABLES=m
# CONFIG_IP6_NF_MATCH_AH is not set
# CONFIG_IP6_NF_MATCH_EUI64 is not set
# CONFIG_IP6_NF_MATCH_FRAG is not set
# CONFIG_IP6_NF_MATCH_OPTS is not set
# CONFIG_IP6_NF_MATCH_HL is not set
# CONFIG_IP6_NF_MATCH_IPV6HEADER is not set
# CONFIG_IP6_NF_MATCH_MH is not set
# CONFIG_IP6_NF_MATCH_RT is not set
# CONFIG_IP6_NF_MATCH_SRH is not set
CONFIG_IP6_NF_FILTER=m
# CONFIG_IP6_NF_TARGET_REJECT is not set
# CONFIG_IP6_NF_MANGLE is not set
# CONFIG_IP6_NF_RAW is not set
# CONFIG_IP6_NF_SECURITY is not set
# CONFIG_BPFILTER is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_NET_DSA is not set
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_6LOWPAN is not set
# CONFIG_IEEE802154 is not set
CONFIG_NET_SCHED=y

#
# Queueing/Scheduling
#
# CONFIG_NET_SCH_CBQ is not set
# CONFIG_NET_SCH_HTB is not set
# CONFIG_NET_SCH_HFSC is not set
# CONFIG_NET_SCH_PRIO is not set
# CONFIG_NET_SCH_MULTIQ is not set
# CONFIG_NET_SCH_RED is not set
# CONFIG_NET_SCH_SFB is not set
# CONFIG_NET_SCH_SFQ is not set
# CONFIG_NET_SCH_TEQL is not set
# CONFIG_NET_SCH_TBF is not set
# CONFIG_NET_SCH_CBS is not set
# CONFIG_NET_SCH_ETF is not set
# CONFIG_NET_SCH_TAPRIO is not set
# CONFIG_NET_SCH_GRED is not set
# CONFIG_NET_SCH_DSMARK is not set
# CONFIG_NET_SCH_NETEM is not set
# CONFIG_NET_SCH_DRR is not set
# CONFIG_NET_SCH_MQPRIO is not set
# CONFIG_NET_SCH_SKBPRIO is not set
# CONFIG_NET_SCH_CHOKE is not set
# CONFIG_NET_SCH_QFQ is not set
# CONFIG_NET_SCH_CODEL is not set
CONFIG_NET_SCH_FQ_CODEL=y
# CONFIG_NET_SCH_CAKE is not set
# CONFIG_NET_SCH_FQ is not set
# CONFIG_NET_SCH_HHF is not set
# CONFIG_NET_SCH_PIE is not set
# CONFIG_NET_SCH_INGRESS is not set
# CONFIG_NET_SCH_PLUG is not set
# CONFIG_NET_SCH_DEFAULT is not set

#
# Classification
#
CONFIG_NET_CLS=y
# CONFIG_NET_CLS_BASIC is not set
# CONFIG_NET_CLS_TCINDEX is not set
# CONFIG_NET_CLS_ROUTE4 is not set
# CONFIG_NET_CLS_FW is not set
# CONFIG_NET_CLS_U32 is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_CLS_FLOW is not set
CONFIG_NET_CLS_CGROUP=y
# CONFIG_NET_CLS_BPF is not set
# CONFIG_NET_CLS_FLOWER is not set
# CONFIG_NET_CLS_MATCHALL is not set
CONFIG_NET_EMATCH=y
CONFIG_NET_EMATCH_STACK=32
# CONFIG_NET_EMATCH_CMP is not set
# CONFIG_NET_EMATCH_NBYTE is not set
# CONFIG_NET_EMATCH_U32 is not set
# CONFIG_NET_EMATCH_META is not set
# CONFIG_NET_EMATCH_TEXT is not set
# CONFIG_NET_EMATCH_IPT is not set
CONFIG_NET_CLS_ACT=y
# CONFIG_NET_ACT_POLICE is not set
# CONFIG_NET_ACT_GACT is not set
# CONFIG_NET_ACT_MIRRED is not set
# CONFIG_NET_ACT_SAMPLE is not set
# CONFIG_NET_ACT_IPT is not set
# CONFIG_NET_ACT_NAT is not set
# CONFIG_NET_ACT_PEDIT is not set
# CONFIG_NET_ACT_SIMP is not set
# CONFIG_NET_ACT_SKBEDIT is not set
# CONFIG_NET_ACT_CSUM is not set
# CONFIG_NET_ACT_VLAN is not set
# CONFIG_NET_ACT_BPF is not set
# CONFIG_NET_ACT_SKBMOD is not set
# CONFIG_NET_ACT_IFE is not set
# CONFIG_NET_ACT_TUNNEL_KEY is not set
CONFIG_NET_SCH_FIFO=y
CONFIG_DCB=y
# CONFIG_DNS_RESOLVER is not set
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_DIAG is not set
CONFIG_MPLS=y
# CONFIG_NET_MPLS_GSO is not set
# CONFIG_MPLS_ROUTING is not set
# CONFIG_NET_NSH is not set
# CONFIG_HSR is not set
CONFIG_NET_SWITCHDEV=y
CONFIG_NET_L3_MASTER_DEV=y
CONFIG_NET_NCSI=y
# CONFIG_NCSI_OEM_CMD_GET_MAC is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
CONFIG_CGROUP_NET_PRIO=y
CONFIG_CGROUP_NET_CLASSID=y
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
CONFIG_BPF_JIT=y
# CONFIG_BPF_STREAM_PARSER is not set
CONFIG_NET_FLOW_LIMIT=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
CONFIG_NET_DROP_MONITOR=y
CONFIG_HAMRADIO=y

#
# Packet Radio protocols
#
# CONFIG_AX25 is not set
# CONFIG_CAN is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
# CONFIG_AF_KCM is not set
CONFIG_FIB_RULES=y
CONFIG_WIRELESS=y
# CONFIG_CFG80211 is not set

#
# CFG80211 needs to be enabled for MAC80211
#
CONFIG_MAC80211_STA_HASH_MAX_SIZE=0
# CONFIG_WIMAX is not set
# CONFIG_RFKILL is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
# CONFIG_PSAMPLE is not set
# CONFIG_NET_IFE is not set
CONFIG_LWTUNNEL=y
CONFIG_LWTUNNEL_BPF=y
CONFIG_DST_CACHE=y
CONFIG_GRO_CELLS=y
# CONFIG_NET_DEVLINK is not set
CONFIG_MAY_USE_DEVLINK=y
# CONFIG_FAILOVER is not set
CONFIG_HAVE_EBPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
# CONFIG_UEVENT_HELPER is not set
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_STANDALONE=y
CONFIG_PREVENT_FIRMWARE_BUILD=y

#
# Firmware loader
#
CONFIG_FW_LOADER=y
CONFIG_EXTRA_FIRMWARE=""
# CONFIG_FW_LOADER_USER_HELPER is not set
CONFIG_ALLOW_DEV_COREDUMP=y
# CONFIG_DEBUG_DRIVER is not set
CONFIG_DEBUG_DEVRES=y
# CONFIG_DEBUG_TEST_DRIVER_REMOVE is not set
# CONFIG_TEST_ASYNC_DRIVER_PROBE is not set
CONFIG_SYS_HYPERVISOR=y
CONFIG_GENERIC_CPU_AUTOPROBE=y
CONFIG_GENERIC_CPU_VULNERABILITIES=y
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
CONFIG_REGMAP_IRQ=y
CONFIG_DMA_SHARED_BUFFER=y
# CONFIG_DMA_FENCE_TRACE is not set
# CONFIG_DMA_CMA is not set

#
# Bus devices
#
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
# CONFIG_GNSS is not set
# CONFIG_MTD is not set
# CONFIG_OF is not set
CONFIG_ARCH_MIGHT_HAVE_PC_PARPORT=y
# CONFIG_PARPORT is not set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG_MESSAGES is not set

#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_NULL_BLK is not set
# CONFIG_BLK_DEV_FD is not set
CONFIG_CDROM=y
# CONFIG_BLK_DEV_PCIESSD_MTIP32XX is not set
# CONFIG_ZRAM is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SKD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_XEN_BLKDEV_FRONTEND is not set
# CONFIG_XEN_BLKDEV_BACKEND is not set
# CONFIG_VIRTIO_BLK is not set
# CONFIG_BLK_DEV_RBD is not set
# CONFIG_BLK_DEV_RSXX is not set

#
# NVME Support
#
# CONFIG_BLK_DEV_NVME is not set
# CONFIG_NVME_FC is not set
# CONFIG_NVME_TARGET is not set

#
# Misc devices
#
# CONFIG_AD525X_DPOT is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_SGI_XP is not set
# CONFIG_HP_ILO is not set
# CONFIG_SGI_GRU is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
# CONFIG_SRAM is not set
# CONFIG_PCI_ENDPOINT_TEST is not set
# CONFIG_C2PORT is not set

#
# EEPROM support
#
# CONFIG_EEPROM_AT24 is not set
# CONFIG_EEPROM_AT25 is not set
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_93XX46 is not set
# CONFIG_EEPROM_IDT_89HPESX is not set
# CONFIG_EEPROM_EE1004 is not set
# CONFIG_CB710_CORE is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_I2C is not set
# CONFIG_ALTERA_STAPL is not set
# CONFIG_INTEL_MEI is not set
# CONFIG_INTEL_MEI_ME is not set
# CONFIG_INTEL_MEI_TXE is not set
# CONFIG_VMWARE_VMCI is not set

#
# Intel MIC & related support
#

#
# Intel MIC Bus Driver
#
# CONFIG_INTEL_MIC_BUS is not set

#
# SCIF Bus Driver
#
# CONFIG_SCIF_BUS is not set

#
# VOP Bus Driver
#
# CONFIG_VOP_BUS is not set

#
# Intel MIC Host Driver
#

#
# Intel MIC Card Driver
#

#
# SCIF Driver
#

#
# Intel MIC Coprocessor State Management (COSM) Drivers
#

#
# VOP Driver
#
# CONFIG_GENWQE is not set
# CONFIG_ECHO is not set
# CONFIG_MISC_RTSX_PCI is not set
# CONFIG_MISC_RTSX_USB is not set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_MQ_DEFAULT is not set
CONFIG_SCSI_PROC_FS=y

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
CONFIG_BLK_DEV_SR_VENDOR=y
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
CONFIG_SCSI_LOWLEVEL=y
# CONFIG_ISCSI_TCP is not set
# CONFIG_ISCSI_BOOT_SYSFS is not set
# CONFIG_SCSI_CXGB3_ISCSI is not set
# CONFIG_SCSI_CXGB4_ISCSI is not set
# CONFIG_SCSI_BNX2_ISCSI is not set
# CONFIG_BE2ISCSI is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_HPSA is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_3W_SAS is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_MVSAS is not set
# CONFIG_SCSI_MVUMI is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_SCSI_ESAS2R is not set
CONFIG_MEGARAID_NEWGEN=y
# CONFIG_MEGARAID_MM is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_MPT3SAS is not set
# CONFIG_SCSI_MPT2SAS is not set
# CONFIG_SCSI_SMARTPQI is not set
# CONFIG_SCSI_UFSHCD is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_MYRB is not set
# CONFIG_SCSI_MYRS is not set
# CONFIG_VMWARE_PVSCSI is not set
# CONFIG_XEN_SCSI_FRONTEND is not set
# CONFIG_SCSI_SNIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_ISCI is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_AM53C974 is not set
# CONFIG_SCSI_WD719X is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_PMCRAID is not set
# CONFIG_SCSI_PM8001 is not set
# CONFIG_SCSI_VIRTIO is not set
# CONFIG_SCSI_LOWLEVEL_PCMCIA is not set
CONFIG_SCSI_DH=y
# CONFIG_SCSI_DH_RDAC is not set
# CONFIG_SCSI_DH_HP_SW is not set
# CONFIG_SCSI_DH_EMC is not set
# CONFIG_SCSI_DH_ALUA is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_ATA_ACPI=y
# CONFIG_SATA_ZPODD is not set
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI=y
CONFIG_SATA_MOBILE_LPM_POLICY=0
# CONFIG_SATA_AHCI_PLATFORM is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_SATA_ACARD_AHCI is not set
# CONFIG_SATA_SIL24 is not set
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_SX4 is not set
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
CONFIG_ATA_PIIX=y
# CONFIG_SATA_DWC is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_SVW is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set

#
# PATA SFF controllers with BMDMA
#
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_ATP867X is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RDC is not set
# CONFIG_PATA_SCH is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_TOSHIBA is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set

#
# PIO-only SFF controllers
#
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_PCMCIA is not set
# CONFIG_PATA_RZ1000 is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_PATA_ACPI is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_LEGACY is not set
CONFIG_MD=y
CONFIG_BLK_DEV_MD=y
CONFIG_MD_AUTODETECT=y
# CONFIG_MD_LINEAR is not set
# CONFIG_MD_RAID0 is not set
# CONFIG_MD_RAID1 is not set
# CONFIG_MD_RAID10 is not set
# CONFIG_MD_RAID456 is not set
# CONFIG_MD_MULTIPATH is not set
# CONFIG_MD_FAULTY is not set
# CONFIG_BCACHE is not set
CONFIG_BLK_DEV_DM_BUILTIN=y
CONFIG_BLK_DEV_DM=y
CONFIG_DM_DEBUG=y
CONFIG_DM_BUFIO=y
CONFIG_DM_DEBUG_BLOCK_MANAGER_LOCKING=y
# CONFIG_DM_DEBUG_BLOCK_STACK_TRACING is not set
# CONFIG_DM_UNSTRIPED is not set
# CONFIG_DM_CRYPT is not set
CONFIG_DM_SNAPSHOT=y
# CONFIG_DM_THIN_PROVISIONING is not set
# CONFIG_DM_CACHE is not set
# CONFIG_DM_WRITECACHE is not set
# CONFIG_DM_ERA is not set
CONFIG_DM_MIRROR=y
# CONFIG_DM_LOG_USERSPACE is not set
# CONFIG_DM_RAID is not set
CONFIG_DM_ZERO=y
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
# CONFIG_DM_FLAKEY is not set
# CONFIG_DM_VERITY is not set
# CONFIG_DM_SWITCH is not set
# CONFIG_DM_LOG_WRITES is not set
# CONFIG_DM_INTEGRITY is not set
# CONFIG_DM_ZONED is not set
# CONFIG_TARGET_CORE is not set
CONFIG_FUSION=y
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_SAS is not set
CONFIG_FUSION_MAX_SGE=40
CONFIG_FUSION_LOGGING=y

#
# IEEE 1394 (FireWire) support
#
# CONFIG_FIREWIRE is not set
# CONFIG_FIREWIRE_NOSY is not set
CONFIG_MACINTOSH_DRIVERS=y
CONFIG_MAC_EMUMOUSEBTN=y
CONFIG_NETDEVICES=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
CONFIG_NET_FC=y
# CONFIG_IFB is not set
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_IPVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_MACSEC is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_TUN is not set
# CONFIG_TUN_VNET_CROSS_LE is not set
# CONFIG_VETH is not set
# CONFIG_VIRTIO_NET is not set
# CONFIG_NLMON is not set
# CONFIG_NET_VRF is not set
# CONFIG_ARCNET is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_3COM=y
# CONFIG_PCMCIA_3C574 is not set
# CONFIG_PCMCIA_3C589 is not set
# CONFIG_VORTEX is not set
# CONFIG_TYPHOON is not set
CONFIG_NET_VENDOR_ADAPTEC=y
# CONFIG_ADAPTEC_STARFIRE is not set
CONFIG_NET_VENDOR_AGERE=y
# CONFIG_ET131X is not set
# CONFIG_NET_VENDOR_ALACRITECH is not set
CONFIG_NET_VENDOR_ALTEON=y
# CONFIG_ACENIC is not set
# CONFIG_ALTERA_TSE is not set
CONFIG_NET_VENDOR_AMAZON=y
# CONFIG_ENA_ETHERNET is not set
CONFIG_NET_VENDOR_AMD=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_PCNET32 is not set
# CONFIG_PCMCIA_NMCLAN is not set
# CONFIG_AMD_XGBE is not set
CONFIG_NET_VENDOR_AQUANTIA=y
# CONFIG_AQTION is not set
CONFIG_NET_VENDOR_ARC=y
CONFIG_NET_VENDOR_ATHEROS=y
# CONFIG_ATL2 is not set
# CONFIG_ATL1 is not set
# CONFIG_ATL1E is not set
# CONFIG_ATL1C is not set
# CONFIG_ALX is not set
# CONFIG_NET_VENDOR_AURORA is not set
CONFIG_NET_VENDOR_BROADCOM=y
# CONFIG_B44 is not set
# CONFIG_BCMGENET is not set
# CONFIG_BNX2 is not set
# CONFIG_CNIC is not set
# CONFIG_TIGON3 is not set
# CONFIG_BNX2X is not set
# CONFIG_SYSTEMPORT is not set
# CONFIG_BNXT is not set
CONFIG_NET_VENDOR_BROCADE=y
# CONFIG_BNA is not set
CONFIG_NET_VENDOR_CADENCE=y
# CONFIG_MACB is not set
# CONFIG_NET_VENDOR_CAVIUM is not set
CONFIG_NET_VENDOR_CHELSIO=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not set
# CONFIG_CHELSIO_T4 is not set
# CONFIG_CHELSIO_T4VF is not set
CONFIG_NET_VENDOR_CISCO=y
# CONFIG_ENIC is not set
CONFIG_NET_VENDOR_CORTINA=y
# CONFIG_CX_ECAT is not set
# CONFIG_DNET is not set
CONFIG_NET_VENDOR_DEC=y
CONFIG_NET_TULIP=y
# CONFIG_DE2104X is not set
# CONFIG_TULIP is not set
# CONFIG_DE4X5 is not set
# CONFIG_WINBOND_840 is not set
# CONFIG_DM9102 is not set
# CONFIG_ULI526X is not set
# CONFIG_PCMCIA_XIRCOM is not set
CONFIG_NET_VENDOR_DLINK=y
# CONFIG_DL2K is not set
# CONFIG_SUNDANCE is not set
CONFIG_NET_VENDOR_EMULEX=y
# CONFIG_BE2NET is not set
# CONFIG_NET_VENDOR_EZCHIP is not set
# CONFIG_NET_VENDOR_FUJITSU is not set
# CONFIG_NET_VENDOR_HP is not set
CONFIG_NET_VENDOR_HUAWEI=y
# CONFIG_HINIC is not set
# CONFIG_NET_VENDOR_I825XX is not set
CONFIG_NET_VENDOR_INTEL=y
# CONFIG_E100 is not set
# CONFIG_E1000 is not set
CONFIG_E1000E=m
CONFIG_E1000E_HWTS=y
# CONFIG_IGB is not set
# CONFIG_IGBVF is not set
# CONFIG_IXGB is not set
# CONFIG_IXGBE is not set
# CONFIG_IXGBEVF is not set
# CONFIG_I40E is not set
# CONFIG_I40EVF is not set
# CONFIG_ICE is not set
# CONFIG_FM10K is not set
# CONFIG_IGC is not set
# CONFIG_JME is not set
CONFIG_NET_VENDOR_MARVELL=y
# CONFIG_MVMDIO is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
CONFIG_NET_VENDOR_MELLANOX=y
# CONFIG_MLX4_EN is not set
# CONFIG_MLX5_CORE is not set
# CONFIG_MLXSW_CORE is not set
# CONFIG_MLXFW is not set
CONFIG_NET_VENDOR_MICREL=y
# CONFIG_KS8842 is not set
# CONFIG_KS8851 is not set
# CONFIG_KS8851_MLL is not set
# CONFIG_KSZ884X_PCI is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
CONFIG_NET_VENDOR_MICROSEMI=y
# CONFIG_MSCC_OCELOT_SWITCH is not set
CONFIG_NET_VENDOR_MYRI=y
# CONFIG_MYRI10GE is not set
# CONFIG_FEALNX is not set
CONFIG_NET_VENDOR_NATSEMI=y
# CONFIG_NATSEMI is not set
# CONFIG_NS83820 is not set
CONFIG_NET_VENDOR_NETERION=y
# CONFIG_S2IO is not set
# CONFIG_VXGE is not set
CONFIG_NET_VENDOR_NETRONOME=y
# CONFIG_NFP is not set
CONFIG_NET_VENDOR_NI=y
# CONFIG_NI_XGE_MANAGEMENT_ENET is not set
CONFIG_NET_VENDOR_8390=y
# CONFIG_PCMCIA_AXNET is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_PCMCIA_PCNET is not set
CONFIG_NET_VENDOR_NVIDIA=y
# CONFIG_FORCEDETH is not set
CONFIG_NET_VENDOR_OKI=y
# CONFIG_ETHOC is not set
CONFIG_NET_VENDOR_PACKET_ENGINES=y
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
CONFIG_NET_VENDOR_QLOGIC=y
# CONFIG_QLA3XXX is not set
# CONFIG_QLCNIC is not set
# CONFIG_QLGE is not set
# CONFIG_NETXEN_NIC is not set
# CONFIG_QED is not set
# CONFIG_NET_VENDOR_QUALCOMM is not set
CONFIG_NET_VENDOR_RDC=y
# CONFIG_R6040 is not set
CONFIG_NET_VENDOR_REALTEK=y
# CONFIG_8139CP is not set
# CONFIG_8139TOO is not set
# CONFIG_R8169 is not set
# CONFIG_NET_VENDOR_RENESAS is not set
CONFIG_NET_VENDOR_ROCKER=y
# CONFIG_NET_VENDOR_SAMSUNG is not set
# CONFIG_NET_VENDOR_SEEQ is not set
CONFIG_NET_VENDOR_SOLARFLARE=y
# CONFIG_SFC is not set
# CONFIG_SFC_FALCON is not set
CONFIG_NET_VENDOR_SILAN=y
# CONFIG_SC92031 is not set
CONFIG_NET_VENDOR_SIS=y
# CONFIG_SIS900 is not set
# CONFIG_SIS190 is not set
CONFIG_NET_VENDOR_SMSC=y
# CONFIG_PCMCIA_SMC91C92 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SMSC911X is not set
# CONFIG_SMSC9420 is not set
CONFIG_NET_VENDOR_SOCIONEXT=y
CONFIG_NET_VENDOR_STMICRO=y
# CONFIG_STMMAC_ETH is not set
CONFIG_NET_VENDOR_SUN=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NIU is not set
# CONFIG_NET_VENDOR_SYNOPSYS is not set
CONFIG_NET_VENDOR_TEHUTI=y
# CONFIG_TEHUTI is not set
CONFIG_NET_VENDOR_TI=y
# CONFIG_TI_CPSW_ALE is not set
# CONFIG_TLAN is not set
CONFIG_NET_VENDOR_VIA=y
# CONFIG_VIA_RHINE is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_NET_VENDOR_XIRCOM=y
# CONFIG_PCMCIA_XIRC2PS is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_NET_SB1000 is not set
CONFIG_MDIO_DEVICE=y
CONFIG_MDIO_BUS=y
# CONFIG_MDIO_BCM_UNIMAC is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_MSCC_MIIM is not set
# CONFIG_MDIO_THUNDER is not set
CONFIG_PHYLIB=y
CONFIG_SWPHY=y
CONFIG_LED_TRIGGER_PHY=y

#
# MII PHY device drivers
#
# CONFIG_AMD_PHY is not set
# CONFIG_AQUANTIA_PHY is not set
# CONFIG_ASIX_PHY is not set
# CONFIG_AT803X_PHY is not set
# CONFIG_BCM7XXX_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_CORTINA_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_DP83822_PHY is not set
# CONFIG_DP83TC811_PHY is not set
# CONFIG_DP83848_PHY is not set
# CONFIG_DP83867_PHY is not set
CONFIG_FIXED_PHY=y
# CONFIG_ICPLUS_PHY is not set
# CONFIG_INTEL_XWAY_PHY is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_MARVELL_10G_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_MICROCHIP_PHY is not set
# CONFIG_MICROCHIP_T1_PHY is not set
# CONFIG_MICROSEMI_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_RENESAS_PHY is not set
# CONFIG_ROCKCHIP_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_TERANETICS_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_XILINX_GMII2RGMII is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_USB_NET_DRIVERS=y
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
# CONFIG_USB_RTL8152 is not set
# CONFIG_USB_LAN78XX is not set
# CONFIG_USB_USBNET is not set
# CONFIG_USB_IPHETH is not set
CONFIG_WLAN=y
# CONFIG_WLAN_VENDOR_ADMTEK is not set
CONFIG_WLAN_VENDOR_ATH=y
# CONFIG_ATH_DEBUG is not set
CONFIG_ATH5K_PCI=y
# CONFIG_WLAN_VENDOR_ATMEL is not set
CONFIG_WLAN_VENDOR_BROADCOM=y
# CONFIG_WLAN_VENDOR_CISCO is not set
CONFIG_WLAN_VENDOR_INTEL=y
CONFIG_WLAN_VENDOR_INTERSIL=y
# CONFIG_HOSTAP is not set
# CONFIG_PRISM54 is not set
CONFIG_WLAN_VENDOR_MARVELL=y
CONFIG_WLAN_VENDOR_MEDIATEK=y
CONFIG_WLAN_VENDOR_RALINK=y
CONFIG_WLAN_VENDOR_REALTEK=y
CONFIG_WLAN_VENDOR_RSI=y
CONFIG_WLAN_VENDOR_ST=y
CONFIG_WLAN_VENDOR_TI=y
CONFIG_WLAN_VENDOR_ZYDAS=y
CONFIG_WLAN_VENDOR_QUANTENNA=y
# CONFIG_PCMCIA_RAYCS is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_XEN_NETDEV_FRONTEND is not set
# CONFIG_XEN_NETDEV_BACKEND is not set
# CONFIG_VMXNET3 is not set
# CONFIG_FUJITSU_ES is not set
# CONFIG_NETDEVSIM is not set
# CONFIG_NET_FAILOVER is not set
CONFIG_ISDN=y
# CONFIG_ISDN_I4L is not set
# CONFIG_ISDN_CAPI is not set
# CONFIG_ISDN_DRV_GIGASET is not set
# CONFIG_HYSDN is not set
# CONFIG_MISDN is not set
# CONFIG_NVM is not set

#
# Input device support
#
CONFIG_INPUT=y
CONFIG_INPUT_LEDS=y
# CONFIG_INPUT_FF_MEMLESS is not set
# CONFIG_INPUT_POLLDEV is not set
# CONFIG_INPUT_SPARSEKMAP is not set
# CONFIG_INPUT_MATRIXKMAP is not set

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_DLINK_DIR685 is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_GPIO is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_TM2_TOUCHKEY is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_BYD=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_SYNAPTICS_SMBUS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_LIFEBOOK=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_MOUSE_PS2_ELANTECH=y
CONFIG_MOUSE_PS2_ELANTECH_SMBUS=y
CONFIG_MOUSE_PS2_SENTELIC=y
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_MOUSE_PS2_FOCALTECH=y
CONFIG_MOUSE_PS2_VMMOUSE=y
CONFIG_MOUSE_PS2_SMBUS=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_BCM5974 is not set
# CONFIG_MOUSE_CYAPA is not set
# CONFIG_MOUSE_ELAN_I2C is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_MOUSE_SYNAPTICS_USB is not set
CONFIG_INPUT_JOYSTICK=y
# CONFIG_JOYSTICK_ANALOG is not set
# CONFIG_JOYSTICK_A3D is not set
# CONFIG_JOYSTICK_ADI is not set
# CONFIG_JOYSTICK_COBRA is not set
# CONFIG_JOYSTICK_GF2K is not set
# CONFIG_JOYSTICK_GRIP is not set
# CONFIG_JOYSTICK_GRIP_MP is not set
# CONFIG_JOYSTICK_GUILLEMOT is not set
# CONFIG_JOYSTICK_INTERACT is not set
# CONFIG_JOYSTICK_SIDEWINDER is not set
# CONFIG_JOYSTICK_TMDC is not set
# CONFIG_JOYSTICK_IFORCE is not set
# CONFIG_JOYSTICK_WARRIOR is not set
# CONFIG_JOYSTICK_MAGELLAN is not set
# CONFIG_JOYSTICK_SPACEORB is not set
# CONFIG_JOYSTICK_SPACEBALL is not set
# CONFIG_JOYSTICK_STINGER is not set
# CONFIG_JOYSTICK_TWIDJOY is not set
# CONFIG_JOYSTICK_ZHENHUA is not set
# CONFIG_JOYSTICK_AS5011 is not set
# CONFIG_JOYSTICK_JOYDUMP is not set
# CONFIG_JOYSTICK_XPAD is not set
# CONFIG_JOYSTICK_PSXPAD_SPI is not set
# CONFIG_JOYSTICK_PXRC is not set
CONFIG_INPUT_TABLET=y
# CONFIG_TABLET_USB_ACECAD is not set
# CONFIG_TABLET_USB_AIPTEK is not set
# CONFIG_TABLET_USB_GTCO is not set
# CONFIG_TABLET_USB_HANWANG is not set
# CONFIG_TABLET_USB_KBTAB is not set
# CONFIG_TABLET_USB_PEGASUS is not set
# CONFIG_TABLET_SERIAL_WACOM4 is not set
CONFIG_INPUT_TOUCHSCREEN=y
CONFIG_TOUCHSCREEN_PROPERTIES=y
# CONFIG_TOUCHSCREEN_ADS7846 is not set
# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_BU21029 is not set
# CONFIG_TOUCHSCREEN_CHIPONE_ICN8505 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
# CONFIG_TOUCHSCREEN_EGALAX_SERIAL is not set
# CONFIG_TOUCHSCREEN_EXC3000 is not set
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_GOODIX is not set
# CONFIG_TOUCHSCREEN_HIDEEP is not set
# CONFIG_TOUCHSCREEN_ILI210X is not set
# CONFIG_TOUCHSCREEN_S6SY761 is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_EKTF2127 is not set
# CONFIG_TOUCHSCREEN_ELAN is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MELFAS_MIP4 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_WDT87XX_I2C is not set
# CONFIG_TOUCHSCREEN_USB_COMPOSITE is not set
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2004 is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_RM_TS is not set
# CONFIG_TOUCHSCREEN_SILEAD is not set
# CONFIG_TOUCHSCREEN_SIS_I2C is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_STMFTS is not set
# CONFIG_TOUCHSCREEN_SURFACE3_SPI is not set
# CONFIG_TOUCHSCREEN_SX8654 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
# CONFIG_TOUCHSCREEN_ZET6223 is not set
# CONFIG_TOUCHSCREEN_ZFORCE is not set
# CONFIG_TOUCHSCREEN_ROHM_BU21023 is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_E3X0_BUTTON is not set
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_MMA8450 is not set
# CONFIG_INPUT_APANEL is not set
# CONFIG_INPUT_GP2A is not set
# CONFIG_INPUT_GPIO_BEEPER is not set
# CONFIG_INPUT_GPIO_DECODER is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
# CONFIG_INPUT_ATI_REMOTE2 is not set
# CONFIG_INPUT_KEYSPAN_REMOTE is not set
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_POWERMATE is not set
# CONFIG_INPUT_YEALINK is not set
# CONFIG_INPUT_CM109 is not set
# CONFIG_INPUT_REGULATOR_HAPTIC is not set
# CONFIG_INPUT_AXP20X_PEK is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_PWM_BEEPER is not set
# CONFIG_INPUT_PWM_VIBRA is not set
# CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_IMS_PCU is not set
# CONFIG_INPUT_CMA3000 is not set
# CONFIG_INPUT_XEN_KBDDEV_FRONTEND is not set
# CONFIG_INPUT_IDEAPAD_SLIDEBAR is not set
# CONFIG_INPUT_DRV260X_HAPTICS is not set
# CONFIG_INPUT_DRV2665_HAPTICS is not set
# CONFIG_INPUT_DRV2667_HAPTICS is not set
# CONFIG_RMI4_CORE is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_ARCH_MIGHT_HAVE_PC_SERIO=y
CONFIG_SERIO_I8042=y
CONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_SERIO_GPIO_PS2 is not set
# CONFIG_USERIO is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_SERIAL_NONSTANDARD=y
# CONFIG_ROCKETPORT is not set
# CONFIG_CYCLADES is not set
# CONFIG_MOXA_INTELLIO is not set
# CONFIG_MOXA_SMARTIO is not set
# CONFIG_SYNCLINK is not set
# CONFIG_SYNCLINKMP is not set
# CONFIG_SYNCLINK_GT is not set
# CONFIG_NOZOMI is not set
# CONFIG_ISI is not set
# CONFIG_N_HDLC is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
CONFIG_DEVMEM=y
# CONFIG_DEVKMEM is not set

#
# Serial drivers
#
CONFIG_SERIAL_EARLYCON=y
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_DEPRECATED_OPTIONS is not set
CONFIG_SERIAL_8250_PNP=y
# CONFIG_SERIAL_8250_FINTEK is not set
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_8250_DMA=y
CONFIG_SERIAL_8250_PCI=y
# CONFIG_SERIAL_8250_EXAR is not set
# CONFIG_SERIAL_8250_CS is not set
CONFIG_SERIAL_8250_NR_UARTS=32
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
CONFIG_SERIAL_8250_EXTENDED=y
CONFIG_SERIAL_8250_MANY_PORTS=y
CONFIG_SERIAL_8250_SHARE_IRQ=y
# CONFIG_SERIAL_8250_DETECT_IRQ is not set
CONFIG_SERIAL_8250_RSA=y
CONFIG_SERIAL_8250_DW=y
CONFIG_SERIAL_8250_RT288X=y
# CONFIG_SERIAL_8250_LPSS is not set
CONFIG_SERIAL_8250_MID=y
# CONFIG_SERIAL_8250_MOXA is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_KGDB_NMI is not set
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
# CONFIG_SERIAL_UARTLITE is not set
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_CONSOLE_POLL=y
# CONFIG_SERIAL_JSM is not set
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_SC16IS7XX is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_ARC is not set
# CONFIG_SERIAL_RP2 is not set
# CONFIG_SERIAL_FSL_LPUART is not set
CONFIG_SERIAL_DEV_BUS=y
CONFIG_SERIAL_DEV_CTRL_TTYPORT=y
CONFIG_HVC_DRIVER=y
CONFIG_HVC_IRQ=y
CONFIG_HVC_XEN=y
CONFIG_HVC_XEN_FRONTEND=y
# CONFIG_VIRTIO_CONSOLE is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_INTEL is not set
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_VIA is not set
CONFIG_HW_RANDOM_VIRTIO=y
CONFIG_NVRAM=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set

#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_SCR24X is not set
# CONFIG_IPWIRELESS is not set
# CONFIG_MWAVE is not set
CONFIG_RAW_DRIVER=y
CONFIG_MAX_RAW_DEVS=8192
CONFIG_HPET=y
# CONFIG_HPET_MMAP is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_UV_MMTIMER is not set
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
# CONFIG_XILLYBUS is not set
# CONFIG_RANDOM_TRUST_CPU is not set

#
# I2C support
#
CONFIG_I2C=y
CONFIG_ACPI_I2C_OPREGION=y
CONFIG_I2C_BOARDINFO=y
CONFIG_I2C_COMPAT=y
# CONFIG_I2C_CHARDEV is not set
# CONFIG_I2C_MUX is not set
CONFIG_I2C_HELPER_AUTO=y
CONFIG_I2C_SMBUS=m
CONFIG_I2C_ALGOBIT=m

#
# I2C Hardware Bus support
#

#
# PC SMBus host controller drivers
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
CONFIG_I2C_I801=m
# CONFIG_I2C_ISCH is not set
# CONFIG_I2C_ISMT is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_CHT_WC is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_NVIDIA_GPU is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set

#
# ACPI drivers
#
# CONFIG_I2C_SCMI is not set

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
CONFIG_I2C_DESIGNWARE_CORE=y
CONFIG_I2C_DESIGNWARE_PLATFORM=y
CONFIG_I2C_DESIGNWARE_SLAVE=y
CONFIG_I2C_DESIGNWARE_PCI=y
CONFIG_I2C_DESIGNWARE_BAYTRAIL=y
# CONFIG_I2C_EMEV2 is not set
# CONFIG_I2C_GPIO is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_DIOLAN_U2C is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_ROBOTFUZZ_OSIF is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_TINY_USB is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_MLXCPLD is not set
# CONFIG_I2C_STUB is not set
CONFIG_I2C_SLAVE=y
# CONFIG_I2C_SLAVE_EEPROM is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y
# CONFIG_SPI_MEM is not set

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
# CONFIG_SPI_AXI_SPI_ENGINE is not set
# CONFIG_SPI_BITBANG is not set
# CONFIG_SPI_CADENCE is not set
# CONFIG_SPI_DESIGNWARE is not set
# CONFIG_SPI_GPIO is not set
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_PXA2XX is not set
# CONFIG_SPI_ROCKCHIP is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_ZYNQMP_GQSPI is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_LOOPBACK_TEST is not set
# CONFIG_SPI_TLE62X0 is not set
# CONFIG_SPI_SLAVE is not set
# CONFIG_SPMI is not set
# CONFIG_HSI is not set
# CONFIG_PPS is not set

#
# PTP clock support
#
# CONFIG_PTP_1588_CLOCK is not set
CONFIG_PINCTRL=y
CONFIG_PINMUX=y
CONFIG_PINCONF=y
CONFIG_GENERIC_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
# CONFIG_PINCTRL_AMD is not set
# CONFIG_PINCTRL_MCP23S08 is not set
# CONFIG_PINCTRL_SX150X is not set
CONFIG_PINCTRL_BAYTRAIL=y
CONFIG_PINCTRL_CHERRYVIEW=y
# CONFIG_PINCTRL_BROXTON is not set
# CONFIG_PINCTRL_CANNONLAKE is not set
# CONFIG_PINCTRL_CEDARFORK is not set
# CONFIG_PINCTRL_DENVERTON is not set
# CONFIG_PINCTRL_GEMINILAKE is not set
# CONFIG_PINCTRL_ICELAKE is not set
# CONFIG_PINCTRL_LEWISBURG is not set
# CONFIG_PINCTRL_SUNRISEPOINT is not set
CONFIG_GPIOLIB=y
CONFIG_GPIOLIB_FASTPATH_LIMIT=512
CONFIG_GPIO_ACPI=y
CONFIG_GPIOLIB_IRQCHIP=y
# CONFIG_DEBUG_GPIO is not set
# CONFIG_GPIO_SYSFS is not set

#
# Memory mapped GPIO drivers
#
# CONFIG_GPIO_AMDPT is not set
# CONFIG_GPIO_DWAPB is not set
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_ICH is not set
# CONFIG_GPIO_LYNXPOINT is not set
# CONFIG_GPIO_MB86S7X is not set
# CONFIG_GPIO_MOCKUP is not set
# CONFIG_GPIO_VX855 is not set

#
# Port-mapped I/O GPIO drivers
#
# CONFIG_GPIO_F7188X is not set
# CONFIG_GPIO_IT87 is not set
# CONFIG_GPIO_SCH is not set
# CONFIG_GPIO_SCH311X is not set
# CONFIG_GPIO_WINBOND is not set
# CONFIG_GPIO_WS16C48 is not set

#
# I2C GPIO expanders
#
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_TPIC2810 is not set

#
# MFD GPIO expanders
#
CONFIG_GPIO_CRYSTAL_COVE=y

#
# PCI GPIO expanders
#
# CONFIG_GPIO_AMD8111 is not set
# CONFIG_GPIO_BT8XX is not set
# CONFIG_GPIO_ML_IOH is not set
# CONFIG_GPIO_PCI_IDIO_16 is not set
# CONFIG_GPIO_PCIE_IDIO_24 is not set
# CONFIG_GPIO_RDC321X is not set

#
# SPI GPIO expanders
#
# CONFIG_GPIO_MAX3191X is not set
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_PISOSR is not set
# CONFIG_GPIO_XRA1403 is not set

#
# USB GPIO expanders
#
# CONFIG_W1 is not set
# CONFIG_POWER_AVS is not set
CONFIG_POWER_RESET=y
# CONFIG_POWER_RESET_RESTART is not set
CONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_TEST_POWER is not set
# CONFIG_CHARGER_ADP5061 is not set
# CONFIG_BATTERY_DS2780 is not set
# CONFIG_BATTERY_DS2781 is not set
# CONFIG_BATTERY_DS2782 is not set
# CONFIG_BATTERY_SBS is not set
# CONFIG_CHARGER_SBS is not set
# CONFIG_BATTERY_BQ27XXX is not set
# CONFIG_BATTERY_MAX17040 is not set
# CONFIG_BATTERY_MAX17042 is not set
# CONFIG_CHARGER_MAX8903 is not set
# CONFIG_CHARGER_LP8727 is not set
# CONFIG_CHARGER_GPIO is not set
# CONFIG_CHARGER_MANAGER is not set
# CONFIG_CHARGER_LTC3651 is not set
# CONFIG_CHARGER_BQ2415X is not set
# CONFIG_CHARGER_BQ24190 is not set
# CONFIG_CHARGER_BQ24257 is not set
# CONFIG_CHARGER_BQ24735 is not set
# CONFIG_CHARGER_BQ25890 is not set
# CONFIG_CHARGER_SMB347 is not set
# CONFIG_BATTERY_GAUGE_LTC2941 is not set
# CONFIG_CHARGER_RT9455 is not set
CONFIG_HWMON=y
# CONFIG_HWMON_DEBUG_CHIP is not set

#
# Native drivers
#
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ABITUGURU3 is not set
# CONFIG_SENSORS_AD7314 is not set
# CONFIG_SENSORS_AD7414 is not set
# CONFIG_SENSORS_AD7418 is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1029 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_ADT7310 is not set
# CONFIG_SENSORS_ADT7410 is not set
# CONFIG_SENSORS_ADT7411 is not set
# CONFIG_SENSORS_ADT7462 is not set
# CONFIG_SENSORS_ADT7470 is not set
# CONFIG_SENSORS_ADT7475 is not set
# CONFIG_SENSORS_ASC7621 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_K10TEMP is not set
# CONFIG_SENSORS_FAM15H_POWER is not set
# CONFIG_SENSORS_APPLESMC is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ASPEED is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS620 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_DELL_SMM is not set
# CONFIG_SENSORS_I5K_AMB is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_F71882FG is not set
# CONFIG_SENSORS_F75375S is not set
# CONFIG_SENSORS_FSCHMD is not set
# CONFIG_SENSORS_FTSTEUTATES is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_G760A is not set
# CONFIG_SENSORS_G762 is not set
# CONFIG_SENSORS_HIH6130 is not set
# CONFIG_SENSORS_I5500 is not set
# CONFIG_SENSORS_CORETEMP is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_JC42 is not set
# CONFIG_SENSORS_POWR1220 is not set
# CONFIG_SENSORS_LINEAGE is not set
# CONFIG_SENSORS_LTC2945 is not set
# CONFIG_SENSORS_LTC2990 is not set
# CONFIG_SENSORS_LTC4151 is not set
# CONFIG_SENSORS_LTC4215 is not set
# CONFIG_SENSORS_LTC4222 is not set
# CONFIG_SENSORS_LTC4245 is not set
# CONFIG_SENSORS_LTC4260 is not set
# CONFIG_SENSORS_LTC4261 is not set
# CONFIG_SENSORS_MAX1111 is not set
# CONFIG_SENSORS_MAX16065 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_MAX1668 is not set
# CONFIG_SENSORS_MAX197 is not set
# CONFIG_SENSORS_MAX31722 is not set
# CONFIG_SENSORS_MAX6621 is not set
# CONFIG_SENSORS_MAX6639 is not set
# CONFIG_SENSORS_MAX6642 is not set
# CONFIG_SENSORS_MAX6650 is not set
# CONFIG_SENSORS_MAX6697 is not set
# CONFIG_SENSORS_MAX31790 is not set
# CONFIG_SENSORS_MCP3021 is not set
# CONFIG_SENSORS_TC654 is not set
# CONFIG_SENSORS_ADCXX is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM70 is not set
# CONFIG_SENSORS_LM73 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_LM93 is not set
# CONFIG_SENSORS_LM95234 is not set
# CONFIG_SENSORS_LM95241 is not set
# CONFIG_SENSORS_LM95245 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_NTC_THERMISTOR is not set
# CONFIG_SENSORS_NCT6683 is not set
# CONFIG_SENSORS_NCT6775 is not set
# CONFIG_SENSORS_NCT7802 is not set
# CONFIG_SENSORS_NCT7904 is not set
# CONFIG_SENSORS_NPCM7XX is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_PMBUS is not set
# CONFIG_SENSORS_SHT15 is not set
# CONFIG_SENSORS_SHT21 is not set
# CONFIG_SENSORS_SHT3x is not set
# CONFIG_SENSORS_SHTC1 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_DME1737 is not set
# CONFIG_SENSORS_EMC1403 is not set
# CONFIG_SENSORS_EMC2103 is not set
# CONFIG_SENSORS_EMC6W201 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_SCH5627 is not set
# CONFIG_SENSORS_SCH5636 is not set
# CONFIG_SENSORS_STTS751 is not set
# CONFIG_SENSORS_SMM665 is not set
# CONFIG_SENSORS_ADC128D818 is not set
# CONFIG_SENSORS_ADS1015 is not set
# CONFIG_SENSORS_ADS7828 is not set
# CONFIG_SENSORS_ADS7871 is not set
# CONFIG_SENSORS_AMC6821 is not set
# CONFIG_SENSORS_INA209 is not set
# CONFIG_SENSORS_INA2XX is not set
# CONFIG_SENSORS_INA3221 is not set
# CONFIG_SENSORS_TC74 is not set
# CONFIG_SENSORS_THMC50 is not set
# CONFIG_SENSORS_TMP102 is not set
# CONFIG_SENSORS_TMP103 is not set
# CONFIG_SENSORS_TMP108 is not set
# CONFIG_SENSORS_TMP401 is not set
# CONFIG_SENSORS_TMP421 is not set
# CONFIG_SENSORS_VIA_CPUTEMP is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83773G is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83795 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83L786NG is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
# CONFIG_SENSORS_XGENE is not set

#
# ACPI drivers
#
# CONFIG_SENSORS_ACPI_POWER is not set
# CONFIG_SENSORS_ATK0110 is not set
CONFIG_THERMAL=y
# CONFIG_THERMAL_STATISTICS is not set
CONFIG_THERMAL_EMERGENCY_POWEROFF_DELAY_MS=0
CONFIG_THERMAL_HWMON=y
CONFIG_THERMAL_WRITABLE_TRIPS=y
CONFIG_THERMAL_DEFAULT_GOV_STEP_WISE=y
# CONFIG_THERMAL_DEFAULT_GOV_FAIR_SHARE is not set
# CONFIG_THERMAL_DEFAULT_GOV_USER_SPACE is not set
# CONFIG_THERMAL_DEFAULT_GOV_POWER_ALLOCATOR is not set
CONFIG_THERMAL_GOV_FAIR_SHARE=y
CONFIG_THERMAL_GOV_STEP_WISE=y
CONFIG_THERMAL_GOV_BANG_BANG=y
CONFIG_THERMAL_GOV_USER_SPACE=y
# CONFIG_THERMAL_GOV_POWER_ALLOCATOR is not set
# CONFIG_CLOCK_THERMAL is not set
# CONFIG_DEVFREQ_THERMAL is not set
# CONFIG_THERMAL_EMULATION is not set
# CONFIG_INTEL_POWERCLAMP is not set
CONFIG_X86_PKG_TEMP_THERMAL=m
# CONFIG_INTEL_SOC_DTS_THERMAL is not set

#
# ACPI INT340X thermal drivers
#
# CONFIG_INT340X_THERMAL is not set
# CONFIG_INTEL_PCH_THERMAL is not set
CONFIG_WATCHDOG=y
CONFIG_WATCHDOG_CORE=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
CONFIG_WATCHDOG_HANDLE_BOOT_ENABLED=y
CONFIG_WATCHDOG_SYSFS=y

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_WDAT_WDT is not set
# CONFIG_XILINX_WATCHDOG is not set
# CONFIG_ZIIRAVE_WATCHDOG is not set
# CONFIG_CADENCE_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
# CONFIG_ACQUIRE_WDT is not set
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not set
# CONFIG_ALIM7101_WDT is not set
# CONFIG_EBC_C384_WDT is not set
# CONFIG_F71808E_WDT is not set
# CONFIG_SP5100_TCO is not set
# CONFIG_SBC_FITPC2_WATCHDOG is not set
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not set
# CONFIG_IBMASR is not set
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_IE6XX_WDT is not set
# CONFIG_ITCO_WDT is not set
# CONFIG_IT8712F_WDT is not set
# CONFIG_IT87_WDT is not set
# CONFIG_HP_WATCHDOG is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_PC87413_WDT is not set
# CONFIG_NV_TCO is not set
# CONFIG_60XX_WDT is not set
# CONFIG_CPU5_WDT is not set
# CONFIG_SMSC_SCH311X_WDT is not set
# CONFIG_SMSC37B787_WDT is not set
# CONFIG_VIA_WDT is not set
# CONFIG_W83627HF_WDT is not set
# CONFIG_W83877F_WDT is not set
# CONFIG_W83977F_WDT is not set
# CONFIG_MACHZ_WDT is not set
# CONFIG_SBC_EPX_C3_WATCHDOG is not set
# CONFIG_NI903X_WDT is not set
# CONFIG_NIC7018_WDT is not set
# CONFIG_MEN_A21_WDT is not set
# CONFIG_XEN_WDT is not set

#
# PCI-based Watchdog Cards
#
# CONFIG_PCIPCWATCHDOG is not set
# CONFIG_WDTPCI is not set

#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set

#
# Watchdog Pretimeout Governors
#
# CONFIG_WATCHDOG_PRETIMEOUT_GOV is not set
CONFIG_SSB_POSSIBLE=y
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_AT91_USART is not set
# CONFIG_MFD_BCM590XX is not set
# CONFIG_MFD_BD9571MWV is not set
CONFIG_MFD_AXP20X=y
CONFIG_MFD_AXP20X_I2C=y
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_MADERA is not set
# CONFIG_PMIC_DA903X is not set
# CONFIG_MFD_DA9052_SPI is not set
# CONFIG_MFD_DA9052_I2C is not set
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_DA9062 is not set
# CONFIG_MFD_DA9063 is not set
# CONFIG_MFD_DA9150 is not set
# CONFIG_MFD_DLN2 is not set
# CONFIG_MFD_MC13XXX_SPI is not set
# CONFIG_MFD_MC13XXX_I2C is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_INTEL_QUARK_I2C_GPIO is not set
# CONFIG_LPC_ICH is not set
# CONFIG_LPC_SCH is not set
CONFIG_INTEL_SOC_PMIC=y
CONFIG_INTEL_SOC_PMIC_CHTWC=y
# CONFIG_INTEL_SOC_PMIC_CHTDC_TI is not set
# CONFIG_MFD_INTEL_LPSS_ACPI is not set
# CONFIG_MFD_INTEL_LPSS_PCI is not set
# CONFIG_MFD_JANZ_CMODIO is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX14577 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX77843 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_MFD_MT6397 is not set
# CONFIG_MFD_MENF21BMC is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_VIPERBOARD is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_MFD_RDC321X is not set
# CONFIG_MFD_RT5033 is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SKY81452 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_SYSCON is not set
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP3943 is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_TI_LMU is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65086 is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS68470 is not set
# CONFIG_MFD_TI_LP873X is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_VX855 is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_RAVE_SP_CORE is not set
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_FIXED_VOLTAGE is not set
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_88PG86X is not set
# CONFIG_REGULATOR_ACT8865 is not set
# CONFIG_REGULATOR_AD5398 is not set
# CONFIG_REGULATOR_AXP20X is not set
# CONFIG_REGULATOR_DA9210 is not set
# CONFIG_REGULATOR_DA9211 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_ISL9305 is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_LTC3589 is not set
# CONFIG_REGULATOR_LTC3676 is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MT6311 is not set
# CONFIG_REGULATOR_PFUZE100 is not set
# CONFIG_REGULATOR_PV88060 is not set
# CONFIG_REGULATOR_PV88080 is not set
# CONFIG_REGULATOR_PV88090 is not set
# CONFIG_REGULATOR_PWM is not set
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
# CONFIG_REGULATOR_TPS65023 is not set
# CONFIG_REGULATOR_TPS6507X is not set
# CONFIG_REGULATOR_TPS65132 is not set
# CONFIG_REGULATOR_TPS6524X is not set
CONFIG_RC_CORE=y
CONFIG_RC_MAP=y
# CONFIG_LIRC is not set
CONFIG_RC_DECODERS=y
CONFIG_IR_NEC_DECODER=y
CONFIG_IR_RC5_DECODER=y
CONFIG_IR_RC6_DECODER=y
CONFIG_IR_JVC_DECODER=y
CONFIG_IR_SONY_DECODER=y
CONFIG_IR_SANYO_DECODER=y
CONFIG_IR_SHARP_DECODER=y
CONFIG_IR_MCE_KBD_DECODER=y
CONFIG_IR_XMP_DECODER=y
# CONFIG_IR_IMON_DECODER is not set
# CONFIG_RC_DEVICES is not set
# CONFIG_MEDIA_SUPPORT is not set

#
# Graphics support
#
CONFIG_AGP=y
CONFIG_AGP_AMD64=y
CONFIG_AGP_INTEL=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_INTEL_GTT=y
CONFIG_VGA_ARB=y
CONFIG_VGA_ARB_MAX_GPUS=16
CONFIG_VGA_SWITCHEROO=y
CONFIG_DRM=m
CONFIG_DRM_MIPI_DSI=y
CONFIG_DRM_DP_AUX_CHARDEV=y
# CONFIG_DRM_DEBUG_SELFTEST is not set
CONFIG_DRM_KMS_HELPER=m
CONFIG_DRM_KMS_FB_HELPER=y
CONFIG_DRM_FBDEV_EMULATION=y
CONFIG_DRM_FBDEV_OVERALLOC=100
CONFIG_DRM_LOAD_EDID_FIRMWARE=y
# CONFIG_DRM_DP_CEC is not set

#
# I2C encoder or helper chips
#
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
# CONFIG_DRM_I2C_NXP_TDA998X is not set
# CONFIG_DRM_I2C_NXP_TDA9950 is not set
# CONFIG_DRM_RADEON is not set
# CONFIG_DRM_AMDGPU is not set

#
# ACP (Audio CoProcessor) Configuration
#

#
# AMD Library routines
#
# CONFIG_DRM_NOUVEAU is not set
CONFIG_DRM_I915=m
# CONFIG_DRM_I915_ALPHA_SUPPORT is not set
CONFIG_DRM_I915_CAPTURE_ERROR=y
CONFIG_DRM_I915_COMPRESS_ERROR=y
CONFIG_DRM_I915_USERPTR=y
CONFIG_DRM_I915_GVT=y
# CONFIG_DRM_VGEM is not set
# CONFIG_DRM_VKMS is not set
# CONFIG_DRM_VMWGFX is not set
# CONFIG_DRM_GMA500 is not set
# CONFIG_DRM_UDL is not set
# CONFIG_DRM_AST is not set
# CONFIG_DRM_MGAG200 is not set
# CONFIG_DRM_CIRRUS_QEMU is not set
# CONFIG_DRM_QXL is not set
# CONFIG_DRM_BOCHS is not set
# CONFIG_DRM_VIRTIO_GPU is not set
CONFIG_DRM_PANEL=y

#
# Display Panels
#
# CONFIG_DRM_PANEL_RASPBERRYPI_TOUCHSCREEN is not set
CONFIG_DRM_BRIDGE=y
CONFIG_DRM_PANEL_BRIDGE=y

#
# Display Interface Bridges
#
# CONFIG_DRM_ANALOGIX_ANX78XX is not set
# CONFIG_DRM_HISI_HIBMC is not set
# CONFIG_DRM_TINYDRM is not set
# CONFIG_DRM_XEN is not set
# CONFIG_DRM_LEGACY is not set
CONFIG_DRM_PANEL_ORIENTATION_QUIRKS=y

#
# Frame buffer Devices
#
CONFIG_FB_CMDLINE=y
CONFIG_FB_NOTIFY=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
CONFIG_FB_BOOT_VESA_SUPPORT=y
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
CONFIG_FB_SYS_FOPS=y
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_MODE_HELPERS is not set
CONFIG_FB_TILEBLITTING=y

#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_UVESA is not set
CONFIG_FB_VESA=y
CONFIG_FB_EFI=y
# CONFIG_FB_N411 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_OPENCORES is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I740 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_MATROX is not set
# CONFIG_FB_RADEON is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_VIA is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_CARMINE is not set
# CONFIG_FB_SMSCUFX is not set
# CONFIG_FB_UDL is not set
# CONFIG_FB_IBM_GXT4500 is not set
# CONFIG_FB_VIRTUAL is not set
CONFIG_XEN_FBDEV_FRONTEND=y
# CONFIG_FB_METRONOME is not set
# CONFIG_FB_MB862XX is not set
# CONFIG_FB_SIMPLE is not set
# CONFIG_FB_SM712 is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_GENERIC is not set
# CONFIG_BACKLIGHT_PWM is not set
# CONFIG_BACKLIGHT_APPLE is not set
# CONFIG_BACKLIGHT_PM8941_WLED is not set
# CONFIG_BACKLIGHT_SAHARA is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3630A is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set
# CONFIG_BACKLIGHT_GPIO is not set
# CONFIG_BACKLIGHT_LV5207LP is not set
# CONFIG_BACKLIGHT_BD6107 is not set
# CONFIG_BACKLIGHT_ARCXCNN is not set
CONFIG_HDMI=y

#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
# CONFIG_VGACON_SOFT_SCROLLBACK_PERSISTENT_ENABLE_BY_DEFAULT is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_DUMMY_CONSOLE_COLUMNS=80
CONFIG_DUMMY_CONSOLE_ROWS=25
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
# CONFIG_FRAMEBUFFER_CONSOLE_DEFERRED_TAKEOVER is not set
CONFIG_LOGO=y
# CONFIG_LOGO_LINUX_MONO is not set
# CONFIG_LOGO_LINUX_VGA16 is not set
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=m
CONFIG_SOUND_OSS_CORE=y
CONFIG_SOUND_OSS_CORE_PRECLAIM=y
CONFIG_SND=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_SEQ_DEVICE=m
CONFIG_SND_JACK=y
CONFIG_SND_JACK_INPUT_DEV=y
CONFIG_SND_OSSEMUL=y
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
CONFIG_SND_PCM_TIMER=y
# CONFIG_SND_HRTIMER is not set
CONFIG_SND_DYNAMIC_MINORS=y
CONFIG_SND_MAX_CARDS=32
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_PROC_FS=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
CONFIG_SND_VMASTER=y
CONFIG_SND_DMA_SGBUF=y
CONFIG_SND_SEQUENCER=m
# CONFIG_SND_SEQ_DUMMY is not set
# CONFIG_SND_SEQUENCER_OSS is not set
CONFIG_SND_DRIVERS=y
# CONFIG_SND_PCSP is not set
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_ALOOP is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_PCI=y
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ASIHPI is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AW2 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CTXFI is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_INDIGOIOX is not set
# CONFIG_SND_INDIGODJX is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
# CONFIG_SND_INTEL8X0 is not set
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_LOLA is not set
# CONFIG_SND_LX6464ES is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SE6X is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set

#
# HD-Audio
#
CONFIG_SND_HDA=m
CONFIG_SND_HDA_INTEL=m
CONFIG_SND_HDA_HWDEP=y
CONFIG_SND_HDA_RECONFIG=y
CONFIG_SND_HDA_INPUT_BEEP=y
CONFIG_SND_HDA_INPUT_BEEP_MODE=0
CONFIG_SND_HDA_PATCH_LOADER=y
CONFIG_SND_HDA_CODEC_REALTEK=m
# CONFIG_SND_HDA_CODEC_ANALOG is not set
# CONFIG_SND_HDA_CODEC_SIGMATEL is not set
# CONFIG_SND_HDA_CODEC_VIA is not set
CONFIG_SND_HDA_CODEC_HDMI=m
# CONFIG_SND_HDA_CODEC_CIRRUS is not set
# CONFIG_SND_HDA_CODEC_CONEXANT is not set
# CONFIG_SND_HDA_CODEC_CA0110 is not set
# CONFIG_SND_HDA_CODEC_CA0132 is not set
# CONFIG_SND_HDA_CODEC_CMEDIA is not set
# CONFIG_SND_HDA_CODEC_SI3054 is not set
CONFIG_SND_HDA_GENERIC=m
CONFIG_SND_HDA_POWER_SAVE_DEFAULT=0
CONFIG_SND_HDA_CORE=m
CONFIG_SND_HDA_COMPONENT=y
CONFIG_SND_HDA_I915=y
CONFIG_SND_HDA_PREALLOC_SIZE=4096
# CONFIG_SND_SPI is not set
CONFIG_SND_USB=y
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_UA101 is not set
# CONFIG_SND_USB_USX2Y is not set
# CONFIG_SND_USB_CAIAQ is not set
# CONFIG_SND_USB_US122L is not set
# CONFIG_SND_USB_6FIRE is not set
# CONFIG_SND_USB_HIFACE is not set
# CONFIG_SND_BCD2000 is not set
# CONFIG_SND_USB_POD is not set
# CONFIG_SND_USB_PODHD is not set
# CONFIG_SND_USB_TONEPORT is not set
# CONFIG_SND_USB_VARIAX is not set
# CONFIG_SND_PCMCIA is not set
# CONFIG_SND_SOC is not set
CONFIG_SND_X86=y
# CONFIG_HDMI_LPE_AUDIO is not set
# CONFIG_SND_XEN_FRONTEND is not set

#
# HID support
#
CONFIG_HID=y
CONFIG_HID_BATTERY_STRENGTH=y
CONFIG_HIDRAW=y
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACCUTOUCH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_APPLEIR is not set
# CONFIG_HID_ASUS is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_BETOP_FF is not set
# CONFIG_HID_BIGBEN_FF is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_CORSAIR is not set
# CONFIG_HID_COUGAR is not set
# CONFIG_HID_PRODIKEYS is not set
# CONFIG_HID_CMEDIA is not set
# CONFIG_HID_CP2112 is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELAN is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_ELO is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_GEMBIRD is not set
# CONFIG_HID_GFRM is not set
# CONFIG_HID_HOLTEK is not set
# CONFIG_HID_GT683R is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_ITE is not set
# CONFIG_HID_JABRA is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LED is not set
# CONFIG_HID_LENOVO is not set
# CONFIG_HID_LOGITECH is not set
CONFIG_HID_MAGICMOUSE=y
# CONFIG_HID_MAYFLASH is not set
CONFIG_HID_REDRAGON=y
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_NTI is not set
CONFIG_HID_NTRIG=y
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PENMOUNT is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PLANTRONICS is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_RETRODE is not set
# CONFIG_HID_ROCCAT is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SONY is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEAM is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_RMI is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THINGM is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_UDRAW_PS3 is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_WIIMOTE is not set
# CONFIG_HID_XINMO is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set
# CONFIG_HID_ALPS is not set

#
# USB HID support
#
CONFIG_USB_HID=y
CONFIG_HID_PID=y
CONFIG_USB_HIDDEV=y

#
# I2C HID support
#
# CONFIG_I2C_HID is not set

#
# Intel ISH HID support
#
# CONFIG_INTEL_ISH_HID is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_SUPPORT=y
CONFIG_USB_COMMON=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB=y
CONFIG_USB_PCI=y
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y

#
# Miscellaneous USB options
#
CONFIG_USB_DEFAULT_PERSIST=y
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_OTG is not set
# CONFIG_USB_OTG_WHITELIST is not set
# CONFIG_USB_LEDS_TRIGGER_USBPORT is not set
CONFIG_USB_MON=y
# CONFIG_USB_WUSB_CBAF is not set

#
# USB Host Controller Drivers
#
# CONFIG_USB_C67X00_HCD is not set
CONFIG_USB_XHCI_HCD=y
# CONFIG_USB_XHCI_DBGCAP is not set
CONFIG_USB_XHCI_PCI=y
# CONFIG_USB_XHCI_PLATFORM is not set
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=y
# CONFIG_USB_EHCI_HCD_PLATFORM is not set
# CONFIG_USB_OXU210HP_HCD is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_FOTG210_HCD is not set
# CONFIG_USB_MAX3421_HCD is not set
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_OHCI_HCD_PCI=y
# CONFIG_USB_OHCI_HCD_PLATFORM is not set
CONFIG_USB_UHCI_HCD=y
# CONFIG_USB_SL811_HCD is not set
# CONFIG_USB_R8A66597_HCD is not set
# CONFIG_USB_HCD_TEST_MODE is not set

#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
# CONFIG_USB_PRINTER is not set
# CONFIG_USB_WDM is not set
# CONFIG_USB_TMC is not set

#
# NOTE: USB_STORAGE depends on SCSI but BLK_DEV_SD may
#

#
# also be needed; see USB_STORAGE Help for more info
#
# CONFIG_USB_STORAGE is not set

#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
# CONFIG_USBIP_CORE is not set
# CONFIG_USB_MUSB_HDRC is not set
# CONFIG_USB_DWC3 is not set
# CONFIG_USB_DWC2 is not set
# CONFIG_USB_CHIPIDEA is not set
# CONFIG_USB_ISP1760 is not set

#
# USB port drivers
#
CONFIG_USB_SERIAL=y
CONFIG_USB_SERIAL_CONSOLE=y
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_SIMPLE is not set
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_CH341 is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP210X is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_F81232 is not set
# CONFIG_USB_SERIAL_F8153X is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_IUU is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_METRO is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_MXUPORT is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
# CONFIG_USB_SERIAL_PL2303 is not set
# CONFIG_USB_SERIAL_OTI6858 is not set
# CONFIG_USB_SERIAL_QCAUX is not set
# CONFIG_USB_SERIAL_QUALCOMM is not set
# CONFIG_USB_SERIAL_SPCP8X5 is not set
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_SYMBOL is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_OPTICON is not set
# CONFIG_USB_SERIAL_XSENS_MT is not set
# CONFIG_USB_SERIAL_WISHBONE is not set
# CONFIG_USB_SERIAL_SSU100 is not set
# CONFIG_USB_SERIAL_QT2 is not set
# CONFIG_USB_SERIAL_UPD78F0730 is not set
# CONFIG_USB_SERIAL_DEBUG is not set

#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_SEVSEG is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
# CONFIG_USB_TEST is not set
# CONFIG_USB_EHSET_TEST_FIXTURE is not set
# CONFIG_USB_ISIGHTFW is not set
# CONFIG_USB_YUREX is not set
# CONFIG_USB_EZUSB_FX2 is not set
# CONFIG_USB_HUB_USB251XB is not set
# CONFIG_USB_HSIC_USB3503 is not set
# CONFIG_USB_HSIC_USB4604 is not set
# CONFIG_USB_LINK_LAYER_TEST is not set
# CONFIG_USB_CHAOSKEY is not set

#
# USB Physical Layer drivers
#
# CONFIG_NOP_USB_XCEIV is not set
# CONFIG_USB_GPIO_VBUS is not set
# CONFIG_USB_ISP1301 is not set
# CONFIG_USB_GADGET is not set
# CONFIG_TYPEC is not set
CONFIG_USB_LED_TRIG=y
# CONFIG_USB_ULPI_BUS is not set
# CONFIG_UWB is not set
# CONFIG_MMC is not set
# CONFIG_MEMSTICK is not set
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
# CONFIG_LEDS_CLASS_FLASH is not set
CONFIG_LEDS_BRIGHTNESS_HW_CHANGED=y

#
# LED drivers
#
# CONFIG_LEDS_APU is not set
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_GPIO is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP3952 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_LP5562 is not set
# CONFIG_LEDS_LP8501 is not set
# CONFIG_LEDS_CLEVO_MAIL is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA963X is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_PWM is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_INTEL_SS4200 is not set
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_TLC591XX is not set
# CONFIG_LEDS_LM355x is not set

#
# LED driver for blink(1) USB RGB LED is under Special HID drivers (HID_THINGM)
#
# CONFIG_LEDS_BLINKM is not set
# CONFIG_LEDS_MLXCPLD is not set
# CONFIG_LEDS_MLXREG is not set
# CONFIG_LEDS_USER is not set
# CONFIG_LEDS_NIC78BX is not set

#
# LED Triggers
#
CONFIG_LEDS_TRIGGERS=y
# CONFIG_LEDS_TRIGGER_TIMER is not set
# CONFIG_LEDS_TRIGGER_ONESHOT is not set
CONFIG_LEDS_TRIGGER_DISK=y
# CONFIG_LEDS_TRIGGER_HEARTBEAT is not set
# CONFIG_LEDS_TRIGGER_BACKLIGHT is not set
# CONFIG_LEDS_TRIGGER_CPU is not set
# CONFIG_LEDS_TRIGGER_ACTIVITY is not set
# CONFIG_LEDS_TRIGGER_GPIO is not set
# CONFIG_LEDS_TRIGGER_DEFAULT_ON is not set

#
# iptables trigger is under Netfilter config (LED target)
#
# CONFIG_LEDS_TRIGGER_TRANSIENT is not set
# CONFIG_LEDS_TRIGGER_CAMERA is not set
CONFIG_LEDS_TRIGGER_PANIC=y
# CONFIG_LEDS_TRIGGER_NETDEV is not set
# CONFIG_LEDS_TRIGGER_PATTERN is not set
CONFIG_ACCESSIBILITY=y
CONFIG_A11Y_BRAILLE_CONSOLE=y
# CONFIG_INFINIBAND is not set
CONFIG_EDAC_ATOMIC_SCRUB=y
CONFIG_EDAC_SUPPORT=y
CONFIG_EDAC=y
CONFIG_EDAC_LEGACY_SYSFS=y
# CONFIG_EDAC_DEBUG is not set
# CONFIG_EDAC_DECODE_MCE is not set
CONFIG_EDAC_GHES=y
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82975X is not set
# CONFIG_EDAC_I3000 is not set
# CONFIG_EDAC_I3200 is not set
# CONFIG_EDAC_IE31200 is not set
# CONFIG_EDAC_X38 is not set
# CONFIG_EDAC_I5400 is not set
# CONFIG_EDAC_I7CORE is not set
# CONFIG_EDAC_I5000 is not set
# CONFIG_EDAC_I5100 is not set
# CONFIG_EDAC_I7300 is not set
# CONFIG_EDAC_SBRIDGE is not set
# CONFIG_EDAC_SKX is not set
# CONFIG_EDAC_PND2 is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_MC146818_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_SYSTOHC is not set
# CONFIG_RTC_DEBUG is not set
# CONFIG_RTC_NVMEM is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_ABB5ZES3 is not set
# CONFIG_RTC_DRV_ABX80X is not set
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF85063 is not set
# CONFIG_RTC_DRV_PCF85363 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8010 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV8803 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1302 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1343 is not set
# CONFIG_RTC_DRV_DS1347 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6916 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RX4581 is not set
# CONFIG_RTC_DRV_RX6110 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_MCP795 is not set
CONFIG_RTC_I2C_AND_SPI=y

#
# SPI and I2C RTC drivers
#
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_PCF2127 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# Platform RTC drivers
#
CONFIG_RTC_DRV_CMOS=y
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1685_FAMILY is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_DS2404 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_FTRTC010 is not set

#
# HID Sensor RTC drivers
#
# CONFIG_RTC_DRV_HID_SENSOR_TIME is not set
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
CONFIG_DMA_ENGINE=y
CONFIG_DMA_VIRTUAL_CHANNELS=y
CONFIG_DMA_ACPI=y
# CONFIG_ALTERA_MSGDMA is not set
# CONFIG_INTEL_IDMA64 is not set
# CONFIG_INTEL_IOATDMA is not set
# CONFIG_QCOM_HIDMA_MGMT is not set
# CONFIG_QCOM_HIDMA is not set
CONFIG_DW_DMAC_CORE=y
# CONFIG_DW_DMAC is not set
CONFIG_DW_DMAC_PCI=y
CONFIG_HSU_DMA=y

#
# DMA Clients
#
CONFIG_ASYNC_TX_DMA=y
# CONFIG_DMATEST is not set

#
# DMABUF options
#
CONFIG_SYNC_FILE=y
# CONFIG_SW_SYNC is not set
# CONFIG_UDMABUF is not set
CONFIG_AUXDISPLAY=y
# CONFIG_HD44780 is not set
# CONFIG_IMG_ASCII_LCD is not set
# CONFIG_UIO is not set
# CONFIG_VFIO is not set
CONFIG_IRQ_BYPASS_MANAGER=m
CONFIG_VIRT_DRIVERS=y
# CONFIG_VBOXGUEST is not set
CONFIG_VIRTIO=y
CONFIG_VIRTIO_MENU=y
CONFIG_VIRTIO_PCI=y
CONFIG_VIRTIO_PCI_LEGACY=y
# CONFIG_VIRTIO_BALLOON is not set
# CONFIG_VIRTIO_INPUT is not set
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
# CONFIG_HYPERV is not set

#
# Xen driver support
#
CONFIG_XEN_BALLOON=y
CONFIG_XEN_SELFBALLOONING=y
# CONFIG_XEN_BALLOON_MEMORY_HOTPLUG is not set
CONFIG_XEN_SCRUB_PAGES_DEFAULT=y
# CONFIG_XEN_DEV_EVTCHN is not set
CONFIG_XEN_BACKEND=y
# CONFIG_XENFS is not set
CONFIG_XEN_SYS_HYPERVISOR=y
CONFIG_XEN_XENBUS_FRONTEND=y
# CONFIG_XEN_GNTDEV is not set
# CONFIG_XEN_GRANT_DEV_ALLOC is not set
# CONFIG_XEN_GRANT_DMA_ALLOC is not set
CONFIG_SWIOTLB_XEN=y
CONFIG_XEN_TMEM=m
# CONFIG_XEN_PCIDEV_BACKEND is not set
# CONFIG_XEN_PVCALLS_FRONTEND is not set
# CONFIG_XEN_PVCALLS_BACKEND is not set
CONFIG_XEN_PRIVCMD=m
# CONFIG_XEN_ACPI_PROCESSOR is not set
# CONFIG_XEN_MCE_LOG is not set
CONFIG_XEN_HAVE_PVMMU=y
CONFIG_XEN_EFI=y
CONFIG_XEN_AUTO_XLATE=y
CONFIG_XEN_ACPI=y
CONFIG_XEN_HAVE_VPMU=y
CONFIG_STAGING=y
# CONFIG_COMEDI is not set
# CONFIG_RTL8192U is not set
# CONFIG_RTLLIB is not set
# CONFIG_R8712U is not set
# CONFIG_RTS5208 is not set
# CONFIG_FB_SM750 is not set
# CONFIG_FB_XGI is not set

#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
CONFIG_STAGING_MEDIA=y

#
# Android
#
# CONFIG_LTE_GDM724X is not set
# CONFIG_GS_FPGABOOT is not set
# CONFIG_UNISYSSPAR is not set
# CONFIG_FB_TFT is not set
# CONFIG_MOST is not set
# CONFIG_GREYBUS is not set
# CONFIG_DRM_VBOXVIDEO is not set
# CONFIG_PI433 is not set

#
# Gasket devices
#
# CONFIG_STAGING_GASKET_FRAMEWORK is not set
# CONFIG_XIL_AXIS_FIFO is not set
# CONFIG_EROFS_FS is not set
CONFIG_X86_PLATFORM_DEVICES=y
# CONFIG_ACER_WMI is not set
# CONFIG_ACER_WIRELESS is not set
# CONFIG_ACERHDF is not set
# CONFIG_ALIENWARE_WMI is not set
# CONFIG_ASUS_LAPTOP is not set
# CONFIG_DCDBAS is not set
# CONFIG_DELL_SMBIOS is not set
# CONFIG_DELL_WMI_AIO is not set
# CONFIG_DELL_WMI_LED is not set
# CONFIG_DELL_SMO8800 is not set
# CONFIG_DELL_RBU is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_FUJITSU_TABLET is not set
# CONFIG_GPD_POCKET_FAN is not set
# CONFIG_HP_ACCEL is not set
# CONFIG_HP_WIRELESS is not set
# CONFIG_HP_WMI is not set
# CONFIG_LG_LAPTOP is not set
# CONFIG_PANASONIC_LAPTOP is not set
# CONFIG_SURFACE3_WMI is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_SENSORS_HDAPS is not set
# CONFIG_INTEL_MENLOW is not set
# CONFIG_EEEPC_LAPTOP is not set
# CONFIG_ASUS_WMI is not set
# CONFIG_ASUS_WIRELESS is not set
CONFIG_ACPI_WMI=m
CONFIG_WMI_BMOF=m
# CONFIG_INTEL_WMI_THUNDERBOLT is not set
# CONFIG_MSI_WMI is not set
# CONFIG_PEAQ_WMI is not set
# CONFIG_TOPSTAR_LAPTOP is not set
# CONFIG_TOSHIBA_BT_RFKILL is not set
# CONFIG_TOSHIBA_HAPS is not set
# CONFIG_TOSHIBA_WMI is not set
# CONFIG_ACPI_CMPC is not set
# CONFIG_INTEL_INT0002_VGPIO is not set
# CONFIG_INTEL_HID_EVENT is not set
# CONFIG_INTEL_VBTN is not set
# CONFIG_INTEL_IPS is not set
CONFIG_INTEL_PMC_CORE=y
# CONFIG_IBM_RTL is not set
# CONFIG_SAMSUNG_LAPTOP is not set
# CONFIG_MXM_WMI is not set
# CONFIG_SAMSUNG_Q10 is not set
# CONFIG_APPLE_GMUX is not set
# CONFIG_INTEL_RST is not set
CONFIG_INTEL_SMARTCONNECT=y
# CONFIG_PVPANIC is not set
# CONFIG_INTEL_PMC_IPC is not set
# CONFIG_SURFACE_PRO3_BUTTON is not set
# CONFIG_INTEL_PUNIT_IPC is not set
# CONFIG_MLX_PLATFORM is not set
CONFIG_INTEL_TURBO_MAX_3=y
# CONFIG_I2C_MULTI_INSTANTIATE is not set
# CONFIG_INTEL_ATOMISP2_PM is not set
CONFIG_PMC_ATOM=y
CONFIG_CHROME_PLATFORMS=y
# CONFIG_CHROMEOS_LAPTOP is not set
# CONFIG_CHROMEOS_PSTORE is not set
# CONFIG_CHROMEOS_TBMC is not set
# CONFIG_CROS_KBD_LED_BACKLIGHT is not set
# CONFIG_MELLANOX_PLATFORM is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
# CONFIG_COMMON_CLK_MAX9485 is not set
# CONFIG_COMMON_CLK_SI5351 is not set
# CONFIG_COMMON_CLK_SI544 is not set
# CONFIG_COMMON_CLK_CDCE706 is not set
# CONFIG_COMMON_CLK_CS2000_CP is not set
# CONFIG_COMMON_CLK_PWM is not set
CONFIG_HWSPINLOCK=y

#
# Clock Source drivers
#
CONFIG_CLKEVT_I8253=y
CONFIG_I8253_LOCK=y
CONFIG_CLKBLD_I8253=y
CONFIG_MAILBOX=y
CONFIG_PCC=y
# CONFIG_ALTERA_MBOX is not set
CONFIG_IOMMU_API=y
CONFIG_IOMMU_SUPPORT=y

#
# Generic IOMMU Pagetable Support
#
# CONFIG_IOMMU_DEBUGFS is not set
# CONFIG_IOMMU_DEFAULT_PASSTHROUGH is not set
CONFIG_IOMMU_IOVA=y
CONFIG_AMD_IOMMU=y
# CONFIG_AMD_IOMMU_V2 is not set
CONFIG_DMAR_TABLE=y
CONFIG_INTEL_IOMMU=y
CONFIG_INTEL_IOMMU_SVM=y
# CONFIG_INTEL_IOMMU_DEFAULT_ON is not set
CONFIG_INTEL_IOMMU_FLOPPY_WA=y
CONFIG_IRQ_REMAP=y

#
# Remoteproc drivers
#
# CONFIG_REMOTEPROC is not set

#
# Rpmsg drivers
#
# CONFIG_RPMSG_QCOM_GLINK_RPM is not set
# CONFIG_RPMSG_VIRTIO is not set
# CONFIG_SOUNDWIRE is not set

#
# SOC (System On Chip) specific Drivers
#

#
# Amlogic SoC drivers
#

#
# Broadcom SoC drivers
#

#
# NXP/Freescale QorIQ SoC drivers
#

#
# i.MX SoC drivers
#

#
# Qualcomm SoC drivers
#
# CONFIG_SOC_TI is not set

#
# Xilinx SoC drivers
#
# CONFIG_XILINX_VCU is not set
CONFIG_PM_DEVFREQ=y

#
# DEVFREQ Governors
#
# CONFIG_DEVFREQ_GOV_SIMPLE_ONDEMAND is not set
# CONFIG_DEVFREQ_GOV_PERFORMANCE is not set
# CONFIG_DEVFREQ_GOV_POWERSAVE is not set
# CONFIG_DEVFREQ_GOV_USERSPACE is not set
# CONFIG_DEVFREQ_GOV_PASSIVE is not set

#
# DEVFREQ Drivers
#
# CONFIG_PM_DEVFREQ_EVENT is not set
CONFIG_EXTCON=y

#
# Extcon Device Drivers
#
# CONFIG_EXTCON_AXP288 is not set
# CONFIG_EXTCON_GPIO is not set
# CONFIG_EXTCON_INTEL_INT3496 is not set
# CONFIG_EXTCON_INTEL_CHT_WC is not set
# CONFIG_EXTCON_MAX3355 is not set
# CONFIG_EXTCON_RT8973A is not set
# CONFIG_EXTCON_SM5502 is not set
# CONFIG_EXTCON_USB_GPIO is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
# CONFIG_NTB is not set
# CONFIG_VME_BUS is not set
CONFIG_PWM=y
CONFIG_PWM_SYSFS=y
CONFIG_PWM_CRC=y
# CONFIG_PWM_LPSS_PCI is not set
# CONFIG_PWM_LPSS_PLATFORM is not set
# CONFIG_PWM_PCA9685 is not set

#
# IRQ chip support
#
CONFIG_ARM_GIC_MAX_NR=1
# CONFIG_IPACK_BUS is not set
CONFIG_RESET_CONTROLLER=y
# CONFIG_RESET_TI_SYSCON is not set
# CONFIG_FMC is not set

#
# PHY Subsystem
#
CONFIG_GENERIC_PHY=y
# CONFIG_BCM_KONA_USB2_PHY is not set
# CONFIG_PHY_PXA_28NM_HSIC is not set
# CONFIG_PHY_PXA_28NM_USB2 is not set
CONFIG_POWERCAP=y
# CONFIG_INTEL_RAPL is not set
# CONFIG_IDLE_INJECT is not set
# CONFIG_MCB is not set

#
# Performance monitor support
#
CONFIG_RAS=y
CONFIG_RAS_CEC=y
# CONFIG_THUNDERBOLT is not set

#
# Android
#
# CONFIG_ANDROID is not set
CONFIG_LIBNVDIMM=y
# CONFIG_BLK_DEV_PMEM is not set
# CONFIG_ND_BLK is not set
CONFIG_ND_CLAIM=y
CONFIG_BTT=y
CONFIG_NVDIMM_PFN=y
CONFIG_NVDIMM_DAX=y
CONFIG_DAX=y
# CONFIG_DEV_DAX is not set
# CONFIG_NVMEM is not set

#
# HW tracing support
#
# CONFIG_STM is not set
# CONFIG_INTEL_TH is not set
# CONFIG_FPGA is not set
CONFIG_PM_OPP=y
# CONFIG_UNISYS_VISORBUS is not set
# CONFIG_SIOX is not set
# CONFIG_SLIMBUS is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_FS_IOMAP=y
# CONFIG_EXT2_FS is not set
# CONFIG_EXT3_FS is not set
CONFIG_EXT4_FS=y
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
CONFIG_EXT4_ENCRYPTION=y
CONFIG_EXT4_FS_ENCRYPTION=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_FS_DAX=y
CONFIG_FS_DAX_PMD=y
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_EXPORTFS_BLOCK_OPS=y
CONFIG_FILE_LOCKING=y
# CONFIG_MANDATORY_FILE_LOCKING is not set
CONFIG_FS_ENCRYPTION=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
CONFIG_FANOTIFY=y
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
# CONFIG_PRINT_QUOTA_WARNING is not set
# CONFIG_QUOTA_DEBUG is not set
CONFIG_QUOTA_TREE=y
# CONFIG_QFMT_V1 is not set
CONFIG_QFMT_V2=y
CONFIG_QUOTACTL=y
CONFIG_QUOTACTL_COMPAT=y
CONFIG_AUTOFS4_FS=y
CONFIG_AUTOFS_FS=y
# CONFIG_FUSE_FS is not set
# CONFIG_OVERLAY_FS is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not set
# CONFIG_UDF_FS is not set

#
# DOS/FAT/NT Filesystems
#
# CONFIG_MSDOS_FS is not set
# CONFIG_VFAT_FS is not set
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_VMCORE=y
# CONFIG_PROC_VMCORE_DEVICE_DUMP is not set
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_PROC_CHILDREN=y
CONFIG_KERNFS=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
CONFIG_TMPFS_POSIX_ACL=y
CONFIG_TMPFS_XATTR=y
CONFIG_HUGETLBFS=y
CONFIG_HUGETLB_PAGE=y
CONFIG_MEMFD_CREATE=y
CONFIG_ARCH_HAS_GIGANTIC_PAGE=y
CONFIG_CONFIGFS_FS=y
CONFIG_EFIVAR_FS=y
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ORANGEFS_FS is not set
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_UBIFS_FS_AUTHENTICATION is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
CONFIG_PSTORE=y
CONFIG_PSTORE_DEFLATE_COMPRESS=y
# CONFIG_PSTORE_LZO_COMPRESS is not set
# CONFIG_PSTORE_LZ4_COMPRESS is not set
# CONFIG_PSTORE_LZ4HC_COMPRESS is not set
# CONFIG_PSTORE_842_COMPRESS is not set
# CONFIG_PSTORE_ZSTD_COMPRESS is not set
CONFIG_PSTORE_COMPRESS=y
CONFIG_PSTORE_DEFLATE_COMPRESS_DEFAULT=y
CONFIG_PSTORE_COMPRESS_DEFAULT="deflate"
# CONFIG_PSTORE_CONSOLE is not set
# CONFIG_PSTORE_PMSG is not set
# CONFIG_PSTORE_FTRACE is not set
# CONFIG_PSTORE_RAM is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
# CONFIG_NFS_FS is not set
# CONFIG_NFSD is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="utf8"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
# CONFIG_NLS_ISO8859_1 is not set
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
# CONFIG_NLS_ISO8859_15 is not set
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
# CONFIG_NLS_UTF8 is not set
# CONFIG_DLM is not set

#
# Security options
#
CONFIG_KEYS=y
CONFIG_KEYS_COMPAT=y
CONFIG_PERSISTENT_KEYRINGS=y
CONFIG_BIG_KEYS=y
CONFIG_ENCRYPTED_KEYS=y
CONFIG_KEY_DH_OPERATIONS=y
# CONFIG_SECURITY_DMESG_RESTRICT is not set
CONFIG_SECURITY=y
CONFIG_SECURITY_WRITABLE_HOOKS=y
CONFIG_SECURITYFS=y
CONFIG_SECURITY_NETWORK=y
CONFIG_PAGE_TABLE_ISOLATION=y
CONFIG_SECURITY_NETWORK_XFRM=y
# CONFIG_SECURITY_PATH is not set
CONFIG_INTEL_TXT=y
CONFIG_LSM_MMAP_MIN_ADDR=65536
CONFIG_HAVE_HARDENED_USERCOPY_ALLOCATOR=y
CONFIG_HARDENED_USERCOPY=y
CONFIG_HARDENED_USERCOPY_FALLBACK=y
CONFIG_FORTIFY_SOURCE=y
# CONFIG_STATIC_USERMODEHELPER is not set
CONFIG_SECURITY_SELINUX=y
CONFIG_SECURITY_SELINUX_BOOTPARAM=y
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1
CONFIG_SECURITY_SELINUX_DISABLE=y
CONFIG_SECURITY_SELINUX_DEVELOP=y
CONFIG_SECURITY_SELINUX_AVC_STATS=y
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1
# CONFIG_SECURITY_SMACK is not set
# CONFIG_SECURITY_TOMOYO is not set
# CONFIG_SECURITY_APPARMOR is not set
# CONFIG_SECURITY_LOADPIN is not set
CONFIG_SECURITY_YAMA=y
# CONFIG_INTEGRITY is not set
CONFIG_DEFAULT_SECURITY_SELINUX=y
# CONFIG_DEFAULT_SECURITY_DAC is not set
CONFIG_DEFAULT_SECURITY="selinux"
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_FIPS=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_AEAD=y
CONFIG_CRYPTO_AEAD2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG=y
CONFIG_CRYPTO_RNG2=y
CONFIG_CRYPTO_RNG_DEFAULT=y
CONFIG_CRYPTO_AKCIPHER2=y
CONFIG_CRYPTO_AKCIPHER=y
CONFIG_CRYPTO_KPP2=y
CONFIG_CRYPTO_KPP=y
CONFIG_CRYPTO_ACOMP2=y
CONFIG_CRYPTO_RSA=y
CONFIG_CRYPTO_DH=y
# CONFIG_CRYPTO_ECDH is not set
CONFIG_CRYPTO_MANAGER=y
CONFIG_CRYPTO_MANAGER2=y
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_MANAGER_DISABLE_TESTS is not set
CONFIG_CRYPTO_GF128MUL=y
CONFIG_CRYPTO_NULL=y
CONFIG_CRYPTO_NULL2=y
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
CONFIG_CRYPTO_CRYPTD=y
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set
CONFIG_CRYPTO_SIMD=y
CONFIG_CRYPTO_GLUE_HELPER_X86=y

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
CONFIG_CRYPTO_GCM=y
# CONFIG_CRYPTO_CHACHA20POLY1305 is not set
# CONFIG_CRYPTO_AEGIS128 is not set
# CONFIG_CRYPTO_AEGIS128L is not set
# CONFIG_CRYPTO_AEGIS256 is not set
# CONFIG_CRYPTO_AEGIS128_AESNI_SSE2 is not set
# CONFIG_CRYPTO_AEGIS128L_AESNI_SSE2 is not set
# CONFIG_CRYPTO_AEGIS256_AESNI_SSE2 is not set
# CONFIG_CRYPTO_MORUS640 is not set
# CONFIG_CRYPTO_MORUS640_SSE2 is not set
# CONFIG_CRYPTO_MORUS1280 is not set
# CONFIG_CRYPTO_MORUS1280_SSE2 is not set
# CONFIG_CRYPTO_MORUS1280_AVX2 is not set
CONFIG_CRYPTO_SEQIV=y
# CONFIG_CRYPTO_ECHAINIV is not set

#
# Block modes
#
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_CFB is not set
CONFIG_CRYPTO_CTR=y
CONFIG_CRYPTO_CTS=y
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_LRW=y
# CONFIG_CRYPTO_OFB is not set
# CONFIG_CRYPTO_PCBC is not set
CONFIG_CRYPTO_XTS=y
# CONFIG_CRYPTO_KEYWRAP is not set

#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
CONFIG_CRYPTO_HMAC=y
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32C_INTEL is not set
# CONFIG_CRYPTO_CRC32 is not set
# CONFIG_CRYPTO_CRC32_PCLMUL is not set
CONFIG_CRYPTO_CRCT10DIF=y
# CONFIG_CRYPTO_CRCT10DIF_PCLMUL is not set
CONFIG_CRYPTO_GHASH=y
# CONFIG_CRYPTO_POLY1305 is not set
# CONFIG_CRYPTO_POLY1305_X86_64 is not set
# CONFIG_CRYPTO_MD4 is not set
CONFIG_CRYPTO_MD5=y
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
CONFIG_CRYPTO_SHA1=y
# CONFIG_CRYPTO_SHA1_SSSE3 is not set
# CONFIG_CRYPTO_SHA256_SSSE3 is not set
# CONFIG_CRYPTO_SHA512_SSSE3 is not set
CONFIG_CRYPTO_SHA256=y
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_SHA3 is not set
# CONFIG_CRYPTO_SM3 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_GHASH_CLMUL_NI_INTEL is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_TI is not set
CONFIG_CRYPTO_AES_X86_64=y
CONFIG_CRYPTO_AES_NI_INTEL=y
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_ARC4 is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_BLOWFISH_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAMELLIA_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA_AESNI_AVX_X86_64 is not set
# CONFIG_CRYPTO_CAMELLIA_AESNI_AVX2_X86_64 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST5_AVX_X86_64 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_CAST6_AVX_X86_64 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_DES3_EDE_X86_64 is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_CHACHA20 is not set
# CONFIG_CRYPTO_CHACHA20_X86_64 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_SERPENT_SSE2_X86_64 is not set
# CONFIG_CRYPTO_SERPENT_AVX_X86_64 is not set
# CONFIG_CRYPTO_SERPENT_AVX2_X86_64 is not set
# CONFIG_CRYPTO_SM4 is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_X86_64 is not set
# CONFIG_CRYPTO_TWOFISH_X86_64_3WAY is not set
# CONFIG_CRYPTO_TWOFISH_AVX_X86_64 is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
CONFIG_CRYPTO_LZO=y
# CONFIG_CRYPTO_842 is not set
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set
# CONFIG_CRYPTO_ZSTD is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
CONFIG_CRYPTO_DRBG_MENU=y
CONFIG_CRYPTO_DRBG_HMAC=y
CONFIG_CRYPTO_DRBG_HASH=y
CONFIG_CRYPTO_DRBG_CTR=y
CONFIG_CRYPTO_DRBG=y
CONFIG_CRYPTO_JITTERENTROPY=y
CONFIG_CRYPTO_USER_API=y
CONFIG_CRYPTO_USER_API_HASH=y
CONFIG_CRYPTO_USER_API_SKCIPHER=y
CONFIG_CRYPTO_USER_API_RNG=y
CONFIG_CRYPTO_USER_API_AEAD=y
# CONFIG_CRYPTO_STATS is not set
CONFIG_CRYPTO_HASH_INFO=y
CONFIG_CRYPTO_HW=y
# CONFIG_CRYPTO_DEV_PADLOCK is not set
CONFIG_CRYPTO_DEV_CCP=y
# CONFIG_CRYPTO_DEV_CCP_DD is not set
# CONFIG_CRYPTO_DEV_QAT_DH895xCC is not set
# CONFIG_CRYPTO_DEV_QAT_C3XXX is not set
# CONFIG_CRYPTO_DEV_QAT_C62X is not set
# CONFIG_CRYPTO_DEV_QAT_DH895xCCVF is not set
# CONFIG_CRYPTO_DEV_QAT_C3XXXVF is not set
# CONFIG_CRYPTO_DEV_QAT_C62XVF is not set
# CONFIG_CRYPTO_DEV_NITROX_CNN55XX is not set
# CONFIG_CRYPTO_DEV_VIRTIO is not set
CONFIG_ASYMMETRIC_KEY_TYPE=y
CONFIG_ASYMMETRIC_PUBLIC_KEY_SUBTYPE=y
CONFIG_X509_CERTIFICATE_PARSER=y
# CONFIG_PKCS8_PRIVATE_KEY_PARSER is not set
CONFIG_PKCS7_MESSAGE_PARSER=y
# CONFIG_PKCS7_TEST_KEY is not set
CONFIG_SIGNED_PE_FILE_VERIFICATION=y

#
# Certificates for signature checking
#
CONFIG_MODULE_SIG_KEY="certs/signing_key.pem"
CONFIG_SYSTEM_TRUSTED_KEYRING=y
CONFIG_SYSTEM_TRUSTED_KEYS=""
# CONFIG_SYSTEM_EXTRA_CERTIFICATE is not set
CONFIG_SECONDARY_TRUSTED_KEYRING=y
CONFIG_SYSTEM_BLACKLIST_KEYRING=y
CONFIG_SYSTEM_BLACKLIST_HASH_LIST=""
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_RATIONAL=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_FIND_FIRST_BIT=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IOMAP=y
CONFIG_ARCH_USE_CMPXCHG_LOCKREF=y
CONFIG_ARCH_HAS_FAST_MULTIPLIER=y
CONFIG_CRC_CCITT=y
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
# CONFIG_CRC_ITU_T is not set
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
# CONFIG_CRC64 is not set
# CONFIG_CRC4 is not set
# CONFIG_CRC7 is not set
# CONFIG_LIBCRC32C is not set
# CONFIG_CRC8 is not set
# CONFIG_RANDOM32_SELFTEST is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
CONFIG_LZ4_DECOMPRESS=y
CONFIG_XZ_DEC=y
CONFIG_XZ_DEC_X86=y
CONFIG_XZ_DEC_POWERPC=y
CONFIG_XZ_DEC_IA64=y
CONFIG_XZ_DEC_ARM=y
CONFIG_XZ_DEC_ARMTHUMB=y
CONFIG_XZ_DEC_SPARC=y
CONFIG_XZ_DEC_BCJ=y
# CONFIG_XZ_DEC_TEST is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_DECOMPRESS_BZIP2=y
CONFIG_DECOMPRESS_LZMA=y
CONFIG_DECOMPRESS_XZ=y
CONFIG_DECOMPRESS_LZO=y
CONFIG_DECOMPRESS_LZ4=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_INTERVAL_TREE=y
CONFIG_XARRAY_MULTI=y
CONFIG_ASSOCIATIVE_ARRAY=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT_MAP=y
CONFIG_HAS_DMA=y
CONFIG_NEED_SG_DMA_LENGTH=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_ARCH_DMA_ADDR_T_64BIT=y
CONFIG_DMA_DIRECT_OPS=y
CONFIG_SWIOTLB=y
CONFIG_SGL_ALLOC=y
CONFIG_IOMMU_HELPER=y
CONFIG_CHECK_SIGNATURE=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_GLOB=y
# CONFIG_GLOB_SELFTEST is not set
CONFIG_NLATTR=y
CONFIG_CLZ_TAB=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
CONFIG_IRQ_POLL=y
CONFIG_MPILIB=y
CONFIG_OID_REGISTRY=y
CONFIG_UCS2_STRING=y
CONFIG_FONT_SUPPORT=y
# CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_SG_POOL=y
CONFIG_ARCH_HAS_SG_CHAIN=y
CONFIG_ARCH_HAS_PMEM_API=y
CONFIG_ARCH_HAS_UACCESS_FLUSHCACHE=y
CONFIG_ARCH_HAS_UACCESS_MCSAFE=y
CONFIG_SBITMAP=y
# CONFIG_STRING_SELFTEST is not set

#
# Kernel hacking
#

#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
CONFIG_CONSOLE_LOGLEVEL_DEFAULT=7
CONFIG_CONSOLE_LOGLEVEL_QUIET=4
CONFIG_MESSAGE_LOGLEVEL_DEFAULT=4
CONFIG_BOOT_PRINTK_DELAY=y
CONFIG_DYNAMIC_DEBUG=y

#
# Compile-time checks and compiler options
#
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_INFO_SPLIT is not set
# CONFIG_DEBUG_INFO_DWARF4 is not set
# CONFIG_GDB_SCRIPTS is not set
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=2048
CONFIG_STRIP_ASM_SYMS=y
# CONFIG_READABLE_ASM is not set
CONFIG_UNUSED_SYMBOLS=y
# CONFIG_PAGE_OWNER is not set
CONFIG_DEBUG_FS=y
CONFIG_HEADERS_CHECK=y
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_SECTION_MISMATCH_WARN_ONLY=y
CONFIG_STACK_VALIDATION=y
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_MAGIC_SYSRQ_DEFAULT_ENABLE=0x0
CONFIG_MAGIC_SYSRQ_SERIAL=y
CONFIG_DEBUG_KERNEL=y

#
# Memory Debugging
#
# CONFIG_PAGE_EXTENSION is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_PAGE_POISONING is not set
# CONFIG_DEBUG_PAGE_REF is not set
CONFIG_DEBUG_RODATA_TEST=y
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_DEBUG_ON is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_STACK_USAGE is not set
CONFIG_DEBUG_VM=y
# CONFIG_DEBUG_VM_VMACACHE is not set
# CONFIG_DEBUG_VM_RB is not set
# CONFIG_DEBUG_VM_PGFLAGS is not set
CONFIG_ARCH_HAS_DEBUG_VIRTUAL=y
# CONFIG_DEBUG_VIRTUAL is not set
CONFIG_DEBUG_MEMORY_INIT=y
# CONFIG_DEBUG_PER_CPU_MAPS is not set
CONFIG_HAVE_DEBUG_STACKOVERFLOW=y
CONFIG_DEBUG_STACKOVERFLOW=y
CONFIG_HAVE_ARCH_KASAN=y
# CONFIG_KASAN is not set
CONFIG_ARCH_HAS_KCOV=y
CONFIG_CC_HAS_SANCOV_TRACE_PC=y
# CONFIG_KCOV is not set
CONFIG_DEBUG_SHIRQ=y

#
# Debug Lockups and Hangs
#
CONFIG_LOCKUP_DETECTOR=y
CONFIG_SOFTLOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=0
CONFIG_HARDLOCKUP_DETECTOR_PERF=y
CONFIG_HARDLOCKUP_CHECK_TIMESTAMP=y
CONFIG_HARDLOCKUP_DETECTOR=y
# CONFIG_BOOTPARAM_HARDLOCKUP_PANIC is not set
CONFIG_BOOTPARAM_HARDLOCKUP_PANIC_VALUE=0
# CONFIG_DETECT_HUNG_TASK is not set
# CONFIG_WQ_WATCHDOG is not set
# CONFIG_PANIC_ON_OOPS is not set
CONFIG_PANIC_ON_OOPS_VALUE=0
CONFIG_PANIC_TIMEOUT=0
CONFIG_SCHED_DEBUG=y
CONFIG_SCHED_INFO=y
CONFIG_SCHEDSTATS=y
# CONFIG_SCHED_STACK_END_CHECK is not set
# CONFIG_DEBUG_TIMEKEEPING is not set

#
# Lock Debugging (spinlocks, mutexes, etc...)
#
CONFIG_LOCK_DEBUGGING_SUPPORT=y
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_WW_MUTEX_SLOWPATH is not set
# CONFIG_DEBUG_RWSEMS is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_DEBUG_ATOMIC_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_LOCK_TORTURE_TEST is not set
# CONFIG_WW_MUTEX_SELFTEST is not set
CONFIG_STACKTRACE=y
# CONFIG_WARN_ALL_UNSEEDED_RANDOM is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
CONFIG_DEBUG_LIST=y
# CONFIG_DEBUG_PI_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_DEBUG_NOTIFIERS is not set
# CONFIG_DEBUG_CREDENTIALS is not set

#
# RCU Debugging
#
# CONFIG_RCU_PERF_TEST is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=60
# CONFIG_RCU_TRACE is not set
# CONFIG_RCU_EQS_DEBUG is not set
# CONFIG_DEBUG_WQ_FORCE_RR_CPU is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_CPU_HOTPLUG_STATE_CONTROL is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
CONFIG_FUNCTION_ERROR_INJECTION=y
# CONFIG_FAULT_INJECTION is not set
CONFIG_LATENCYTOP=y
CONFIG_USER_STACKTRACE_SUPPORT=y
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_FENTRY=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACER_MAX_TRACE=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_PREEMPTIRQ_EVENTS is not set
# CONFIG_IRQSOFF_TRACER is not set
CONFIG_SCHED_TRACER=y
CONFIG_HWLAT_TRACER=y
CONFIG_FTRACE_SYSCALLS=y
CONFIG_TRACER_SNAPSHOT=y
# CONFIG_TRACER_SNAPSHOT_PER_CPU_SWAP is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
CONFIG_STACK_TRACER=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_KPROBE_EVENTS=y
# CONFIG_KPROBE_EVENTS_ON_NOTRACE is not set
CONFIG_UPROBE_EVENTS=y
CONFIG_BPF_EVENTS=y
CONFIG_PROBE_EVENTS=y
CONFIG_DYNAMIC_FTRACE=y
CONFIG_DYNAMIC_FTRACE_WITH_REGS=y
CONFIG_FUNCTION_PROFILER=y
# CONFIG_BPF_KPROBE_OVERRIDE is not set
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
CONFIG_MMIOTRACE=y
CONFIG_TRACING_MAP=y
CONFIG_HIST_TRIGGERS=y
# CONFIG_MMIOTRACE_TEST is not set
# CONFIG_TRACEPOINT_BENCHMARK is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set
CONFIG_TRACE_EVAL_MAP_FILE=y
# CONFIG_TRACING_EVENTS_GPIO is not set
CONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_DMA_API_DEBUG is not set
CONFIG_RUNTIME_TESTING_MENU=y
# CONFIG_LKDTM is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_TEST_SORT is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_PERCPU_TEST is not set
CONFIG_ATOMIC64_SELFTEST=y
# CONFIG_TEST_HEXDUMP is not set
# CONFIG_TEST_STRING_HELPERS is not set
CONFIG_TEST_KSTRTOX=y
# CONFIG_TEST_PRINTF is not set
# CONFIG_TEST_BITMAP is not set
# CONFIG_TEST_BITFIELD is not set
# CONFIG_TEST_UUID is not set
# CONFIG_TEST_XARRAY is not set
# CONFIG_TEST_OVERFLOW is not set
# CONFIG_TEST_RHASHTABLE is not set
# CONFIG_TEST_HASH is not set
# CONFIG_TEST_IDA is not set
# CONFIG_TEST_LKM is not set
# CONFIG_TEST_USER_COPY is not set
# CONFIG_TEST_BPF is not set
# CONFIG_FIND_BIT_BENCHMARK is not set
# CONFIG_TEST_FIRMWARE is not set
# CONFIG_TEST_SYSCTL is not set
# CONFIG_TEST_UDELAY is not set
# CONFIG_TEST_STATIC_KEYS is not set
# CONFIG_TEST_KMOD is not set
# CONFIG_TEST_MEMCAT_P is not set
# CONFIG_MEMTEST is not set
CONFIG_BUG_ON_DATA_CORRUPTION=y
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
CONFIG_KGDB=y
CONFIG_KGDB_SERIAL_CONSOLE=y
CONFIG_KGDB_TESTS=y
# CONFIG_KGDB_TESTS_ON_BOOT is not set
CONFIG_KGDB_LOW_LEVEL_TRAP=y
# CONFIG_KGDB_KDB is not set
CONFIG_ARCH_HAS_UBSAN_SANITIZE_ALL=y
# CONFIG_UBSAN is not set
CONFIG_ARCH_HAS_DEVMEM_IS_ALLOWED=y
CONFIG_STRICT_DEVMEM=y
CONFIG_IO_STRICT_DEVMEM=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_EARLY_PRINTK_USB=y
# CONFIG_X86_VERBOSE_BOOTUP is not set
CONFIG_EARLY_PRINTK=y
CONFIG_EARLY_PRINTK_DBGP=y
CONFIG_EARLY_PRINTK_EFI=y
CONFIG_EARLY_PRINTK_USB_XDBC=y
CONFIG_X86_PTDUMP_CORE=y
# CONFIG_X86_PTDUMP is not set
# CONFIG_EFI_PGT_DUMP is not set
CONFIG_DEBUG_WX=y
CONFIG_DOUBLEFAULT=y
# CONFIG_DEBUG_TLBFLUSH is not set
# CONFIG_IOMMU_DEBUG is not set
CONFIG_HAVE_MMIOTRACE_SUPPORT=y
CONFIG_X86_DECODER_SELFTEST=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_IO_DELAY_TYPE_NONE=3
CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not set
CONFIG_DEFAULT_IO_DELAY_TYPE=0
CONFIG_DEBUG_BOOT_PARAMS=y
# CONFIG_CPA_DEBUG is not set
CONFIG_OPTIMIZE_INLINING=y
# CONFIG_DEBUG_ENTRY is not set
# CONFIG_DEBUG_NMI_SELFTEST is not set
# CONFIG_X86_DEBUG_FPU is not set
# CONFIG_PUNIT_ATOM_DEBUG is not set
CONFIG_UNWINDER_ORC=y
# CONFIG_UNWINDER_FRAME_POINTER is not set

[-- Attachment #3: 0001-tracepoints-Add-a-direct-call-or-an-iterator.patch --]
[-- Type: text/x-patch, Size: 10979 bytes --]

From bbbd55dc988fae148ce00cf4512760babbf8a9e0 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Date: Fri, 5 Oct 2018 09:31:43 -0400
Subject: [PATCH] tracepoints: Add a direct call or an iterator

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
 include/linux/tracepoint-defs.h |  2 +
 include/linux/tracepoint.h      | 73 ++++++++++++++++++++++-----------
 include/trace/define_trace.h    | 14 +++----
 kernel/tracepoint.c             | 29 +++++++++++--
 4 files changed, 82 insertions(+), 36 deletions(-)

diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h
index 49ba9cde7e4b..8013fc442964 100644
--- a/include/linux/tracepoint-defs.h
+++ b/include/linux/tracepoint-defs.h
@@ -30,6 +30,8 @@ struct tracepoint_func {
 struct tracepoint {
 	const char *name;		/* Tracepoint name */
 	struct static_key key;
+	void **function_ptr;
+	void *iterator;
 	int (*regfunc)(void);
 	void (*unregfunc)(void);
 	struct tracepoint_func __rcu *funcs;
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index 538ba1a58f5b..b60d547c44ba 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -94,7 +94,9 @@ extern int syscall_regfunc(void);
 extern void syscall_unregfunc(void);
 #endif /* CONFIG_HAVE_SYSCALL_TRACEPOINTS */
 
+#ifndef PARAMS
 #define PARAMS(args...) args
+#endif
 
 #define TRACE_DEFINE_ENUM(x)
 #define TRACE_DEFINE_SIZEOF(x)
@@ -161,12 +163,11 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
  * as "(void *, void)". The DECLARE_TRACE_NOARGS() will pass in just
  * "void *data", where as the DECLARE_TRACE() will pass in "void *data, proto".
  */
-#define __DO_TRACE(tp, proto, args, cond, rcuidle)			\
+#define __DO_TRACE(name, proto, args, cond, rcuidle)			\
 	do {								\
 		struct tracepoint_func *it_func_ptr;			\
-		void *it_func;						\
-		void *__data;						\
 		int __maybe_unused idx = 0;				\
+		void *__data;						\
 									\
 		if (!(cond))						\
 			return;						\
@@ -186,14 +187,12 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
 			rcu_irq_enter_irqson();				\
 		}							\
 									\
-		it_func_ptr = rcu_dereference_raw((tp)->funcs);		\
-									\
+		it_func_ptr =						\
+			rcu_dereference_raw((&__tracepoint_##name)->funcs); \
 		if (it_func_ptr) {					\
-			do {						\
-				it_func = (it_func_ptr)->func;		\
-				__data = (it_func_ptr)->data;		\
-				((void(*)(proto))(it_func))(args);	\
-			} while ((++it_func_ptr)->func);		\
+			__data = (it_func_ptr)->data;			\
+			/* printk("%pS\n", __tp_func_##name); */		\
+			__tp_func_##name(args);				\
 		}							\
 									\
 		if (rcuidle) {						\
@@ -209,7 +208,7 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
 	static inline void trace_##name##_rcuidle(proto)		\
 	{								\
 		if (static_key_false(&__tracepoint_##name.key))		\
-			__DO_TRACE(&__tracepoint_##name,		\
+			__DO_TRACE(name,				\
 				TP_PROTO(data_proto),			\
 				TP_ARGS(data_args),			\
 				TP_CONDITION(cond), 1);			\
@@ -231,11 +230,13 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
  * poking RCU a bit.
  */
 #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
+	extern void __tracepoint_iter_##name(data_proto);		\
+	extern void (*__tp_func_##name)(data_proto);			\
 	extern struct tracepoint __tracepoint_##name;			\
 	static inline void trace_##name(proto)				\
 	{								\
 		if (static_key_false(&__tracepoint_##name.key))		\
-			__DO_TRACE(&__tracepoint_##name,		\
+			__DO_TRACE(name,				\
 				TP_PROTO(data_proto),			\
 				TP_ARGS(data_args),			\
 				TP_CONDITION(cond), 0);			\
@@ -281,21 +282,43 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
  * structures, so we create an array of pointers that will be used for iteration
  * on the tracepoints.
  */
-#define DEFINE_TRACE_FN(name, reg, unreg)				 \
-	static const char __tpstrtab_##name[]				 \
-	__attribute__((section("__tracepoints_strings"))) = #name;	 \
-	struct tracepoint __tracepoint_##name				 \
-	__attribute__((section("__tracepoints"), used)) =		 \
-		{ __tpstrtab_##name, STATIC_KEY_INIT_FALSE, reg, unreg, NULL };\
-	__TRACEPOINT_ENTRY(name);
+#define DEFINE_TRACE_FN(name, reg, unreg, proto, args)			\
+	static const char __tpstrtab_##name[]				\
+	__attribute__((section("__tracepoints_strings"))) = #name;	\
+	void __tracepoint_iter_##name(void *__data, proto);		\
+	void (*__tp_func_##name)(void *__data, proto) =			\
+		__tracepoint_iter_##name;				\
+	struct tracepoint __tracepoint_##name				\
+	__attribute__((section("__tracepoints"), used)) =		\
+		{ __tpstrtab_##name, STATIC_KEY_INIT_FALSE,		\
+		  (void **)&__tp_func_##name, __tracepoint_iter_##name,	\
+		  reg, unreg, NULL };					\
+	__TRACEPOINT_ENTRY(name);					\
+	void __tracepoint_iter_##name(void *__data, proto)		\
+	{								\
+		struct tracepoint_func *it_func_ptr;			\
+		void *it_func;						\
+									\
+		it_func_ptr =						\
+			rcu_dereference_raw((&__tracepoint_##name)->funcs); \
+		do {							\
+			it_func = (it_func_ptr)->func;			\
+			__data = (it_func_ptr)->data;			\
+			((void(*)(void *, proto))(it_func))(__data, args); \
+		} while ((++it_func_ptr)->func);			\
+		return 0;						\
+	}
 
-#define DEFINE_TRACE(name)						\
-	DEFINE_TRACE_FN(name, NULL, NULL);
+#define DEFINE_TRACE(name, proto, args)		\
+	DEFINE_TRACE_FN(name, NULL, NULL, PARAMS(proto), PARAMS(args));
 
 #define EXPORT_TRACEPOINT_SYMBOL_GPL(name)				\
-	EXPORT_SYMBOL_GPL(__tracepoint_##name)
+	EXPORT_SYMBOL_GPL(__tracepoint_##name);				\
+	EXPORT_SYMBOL_GPL(__tp_func_##name)
 #define EXPORT_TRACEPOINT_SYMBOL(name)					\
-	EXPORT_SYMBOL(__tracepoint_##name)
+	EXPORT_SYMBOL(__tracepoint_##name);				\
+	EXPORT_SYMBOL(__tp_func_##name)
+
 
 #else /* !TRACEPOINTS_ENABLED */
 #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
@@ -324,8 +347,8 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
 		return false;						\
 	}
 
-#define DEFINE_TRACE_FN(name, reg, unreg)
-#define DEFINE_TRACE(name)
+#define DEFINE_TRACE_FN(name, reg, unreg, proto, args)
+#define DEFINE_TRACE(name, proto, args)
 #define EXPORT_TRACEPOINT_SYMBOL_GPL(name)
 #define EXPORT_TRACEPOINT_SYMBOL(name)
 
diff --git a/include/trace/define_trace.h b/include/trace/define_trace.h
index cb30c5532144..c19aea44efb2 100644
--- a/include/trace/define_trace.h
+++ b/include/trace/define_trace.h
@@ -25,7 +25,7 @@
 
 #undef TRACE_EVENT
 #define TRACE_EVENT(name, proto, args, tstruct, assign, print)	\
-	DEFINE_TRACE(name)
+	DEFINE_TRACE(name, PARAMS(proto), PARAMS(args))
 
 #undef TRACE_EVENT_CONDITION
 #define TRACE_EVENT_CONDITION(name, proto, args, cond, tstruct, assign, print) \
@@ -39,24 +39,24 @@
 #undef TRACE_EVENT_FN
 #define TRACE_EVENT_FN(name, proto, args, tstruct,		\
 		assign, print, reg, unreg)			\
-	DEFINE_TRACE_FN(name, reg, unreg)
+	DEFINE_TRACE_FN(name, reg, unreg, PARAMS(proto), PARAMS(args))
 
 #undef TRACE_EVENT_FN_COND
 #define TRACE_EVENT_FN_COND(name, proto, args, cond, tstruct,		\
 		assign, print, reg, unreg)			\
-	DEFINE_TRACE_FN(name, reg, unreg)
+	DEFINE_TRACE_FN(name, reg, unreg, PARAMS(proto), PARAMS(args))
 
 #undef DEFINE_EVENT
 #define DEFINE_EVENT(template, name, proto, args) \
-	DEFINE_TRACE(name)
+	DEFINE_TRACE(name, PARAMS(proto), PARAMS(args))
 
 #undef DEFINE_EVENT_FN
 #define DEFINE_EVENT_FN(template, name, proto, args, reg, unreg) \
-	DEFINE_TRACE_FN(name, reg, unreg)
+	DEFINE_TRACE_FN(name, reg, unreg, PARAMS(proto), PARAMS(args))
 
 #undef DEFINE_EVENT_PRINT
 #define DEFINE_EVENT_PRINT(template, name, proto, args, print)	\
-	DEFINE_TRACE(name)
+	DEFINE_TRACE(name, PARAMS(proto), PARAMS(args))
 
 #undef DEFINE_EVENT_CONDITION
 #define DEFINE_EVENT_CONDITION(template, name, proto, args, cond) \
@@ -64,7 +64,7 @@
 
 #undef DECLARE_TRACE
 #define DECLARE_TRACE(name, proto, args)	\
-	DEFINE_TRACE(name)
+	DEFINE_TRACE(name, PARAMS(proto), PARAMS(args))
 
 #undef TRACE_INCLUDE
 #undef __TRACE_INCLUDE
diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index a3be42304485..7e1f34edd1d7 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -140,7 +140,7 @@ static void debug_print_probes(struct tracepoint_func *funcs)
 
 static struct tracepoint_func *
 func_add(struct tracepoint_func **funcs, struct tracepoint_func *tp_func,
-	 int prio)
+	 int prio, int *tot_probes)
 {
 	struct tracepoint_func *old, *new;
 	int nr_probes = 0;
@@ -183,11 +183,12 @@ func_add(struct tracepoint_func **funcs, struct tracepoint_func *tp_func,
 	new[nr_probes + 1].func = NULL;
 	*funcs = new;
 	debug_print_probes(*funcs);
+	*tot_probes = nr_probes + 1;
 	return old;
 }
 
 static void *func_remove(struct tracepoint_func **funcs,
-		struct tracepoint_func *tp_func)
+		struct tracepoint_func *tp_func, int *left)
 {
 	int nr_probes = 0, nr_del = 0, i;
 	struct tracepoint_func *old, *new;
@@ -241,6 +242,7 @@ static int tracepoint_add_func(struct tracepoint *tp,
 			       struct tracepoint_func *func, int prio)
 {
 	struct tracepoint_func *old, *tp_funcs;
+	int probes = 0;
 	int ret;
 
 	if (tp->regfunc && !static_key_enabled(&tp->key)) {
@@ -251,7 +253,7 @@ static int tracepoint_add_func(struct tracepoint *tp,
 
 	tp_funcs = rcu_dereference_protected(tp->funcs,
 			lockdep_is_held(&tracepoints_mutex));
-	old = func_add(&tp_funcs, func, prio);
+	old = func_add(&tp_funcs, func, prio, &probes);
 	if (IS_ERR(old)) {
 		WARN_ON_ONCE(PTR_ERR(old) != -ENOMEM);
 		return PTR_ERR(old);
@@ -266,6 +268,15 @@ static int tracepoint_add_func(struct tracepoint *tp,
 	rcu_assign_pointer(tp->funcs, tp_funcs);
 	if (!static_key_enabled(&tp->key))
 		static_key_slow_inc(&tp->key);
+
+	if (probes == 1) {
+		printk("make direct call to %pS\n", tp_funcs->func);
+		*tp->function_ptr = tp_funcs->func;
+	} else {
+		printk("[%d] make call to iterator %pS\n", probes, tp->iterator);
+		*tp->function_ptr = tp->iterator;
+	}
+
 	release_probes(old);
 	return 0;
 }
@@ -280,10 +291,11 @@ static int tracepoint_remove_func(struct tracepoint *tp,
 		struct tracepoint_func *func)
 {
 	struct tracepoint_func *old, *tp_funcs;
+	int probes_left = 0;
 
 	tp_funcs = rcu_dereference_protected(tp->funcs,
 			lockdep_is_held(&tracepoints_mutex));
-	old = func_remove(&tp_funcs, func);
+	old = func_remove(&tp_funcs, func, &probes_left);
 	if (IS_ERR(old)) {
 		WARN_ON_ONCE(PTR_ERR(old) != -ENOMEM);
 		return PTR_ERR(old);
@@ -297,6 +309,15 @@ static int tracepoint_remove_func(struct tracepoint *tp,
 		if (static_key_enabled(&tp->key))
 			static_key_slow_dec(&tp->key);
 	}
+
+	if (probes_left == 1) {
+		printk("make direct call to %pS\n", tp_funcs->func);
+		*tp->function_ptr = tp_funcs->func;
+	} else {
+		printk("[%d] make call to iterator %pS\n", probes_left, tp->iterator);
+		*tp->function_ptr = tp->iterator;
+	}
+
 	rcu_assign_pointer(tp->funcs, tp_funcs);
 	release_probes(old);
 	return 0;
-- 
2.19.1


[-- Attachment #4: 0002-tracepoints-Implement-it-with-dynamic-functions.patch --]
[-- Type: text/x-patch, Size: 5372 bytes --]

From 341d8326ef359ebfdf7923e01e225f653111c304 Mon Sep 17 00:00:00 2001
From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
Date: Fri, 5 Oct 2018 09:31:43 -0400
Subject: [PATCH] tracepoints: Implement it with dynamic functions

Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
---
 include/linux/tracepoint-defs.h |  4 +++-
 include/linux/tracepoint.h      | 24 ++++++++++++------------
 kernel/tracepoint.c             |  8 ++++----
 3 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/include/linux/tracepoint-defs.h b/include/linux/tracepoint-defs.h
index 8013fc442964..ae16672bea61 100644
--- a/include/linux/tracepoint-defs.h
+++ b/include/linux/tracepoint-defs.h
@@ -11,6 +11,8 @@
 #include <linux/atomic.h>
 #include <linux/static_key.h>
 
+struct static_call_key;
+
 struct trace_print_flags {
 	unsigned long		mask;
 	const char		*name;
@@ -30,7 +32,7 @@ struct tracepoint_func {
 struct tracepoint {
 	const char *name;		/* Tracepoint name */
 	struct static_key key;
-	void **function_ptr;
+	struct static_call_key *static_call_key;
 	void *iterator;
 	int (*regfunc)(void);
 	void (*unregfunc)(void);
diff --git a/include/linux/tracepoint.h b/include/linux/tracepoint.h
index b60d547c44ba..e0d787a7e68b 100644
--- a/include/linux/tracepoint.h
+++ b/include/linux/tracepoint.h
@@ -21,6 +21,7 @@
 #include <linux/cpumask.h>
 #include <linux/rcupdate.h>
 #include <linux/tracepoint-defs.h>
+#include <linux/static_call.h>
 
 struct module;
 struct tracepoint;
@@ -191,8 +192,7 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
 			rcu_dereference_raw((&__tracepoint_##name)->funcs); \
 		if (it_func_ptr) {					\
 			__data = (it_func_ptr)->data;			\
-			/* printk("%pS\n", __tp_func_##name); */		\
-			__tp_func_##name(args);				\
+			static_call(__tp_func_##name, args);		\
 		}							\
 									\
 		if (rcuidle) {						\
@@ -230,8 +230,8 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
  * poking RCU a bit.
  */
 #define __DECLARE_TRACE(name, proto, args, cond, data_proto, data_args) \
-	extern void __tracepoint_iter_##name(data_proto);		\
-	extern void (*__tp_func_##name)(data_proto);			\
+	extern int __tracepoint_iter_##name(data_proto);		\
+	DECLARE_STATIC_CALL(__tp_func_##name, __tracepoint_iter_##name); \
 	extern struct tracepoint __tracepoint_##name;			\
 	static inline void trace_##name(proto)				\
 	{								\
@@ -285,16 +285,15 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
 #define DEFINE_TRACE_FN(name, reg, unreg, proto, args)			\
 	static const char __tpstrtab_##name[]				\
 	__attribute__((section("__tracepoints_strings"))) = #name;	\
-	void __tracepoint_iter_##name(void *__data, proto);		\
-	void (*__tp_func_##name)(void *__data, proto) =			\
-		__tracepoint_iter_##name;				\
+	int __tracepoint_iter_##name(void *__data, proto);		\
+	extern struct static_call_key __tp_func_##name;			\
 	struct tracepoint __tracepoint_##name				\
 	__attribute__((section("__tracepoints"), used)) =		\
 		{ __tpstrtab_##name, STATIC_KEY_INIT_FALSE,		\
-		  (void **)&__tp_func_##name, __tracepoint_iter_##name,	\
+		  &__tp_func_##name, __tracepoint_iter_##name,		\
 		  reg, unreg, NULL };					\
 	__TRACEPOINT_ENTRY(name);					\
-	void __tracepoint_iter_##name(void *__data, proto)		\
+	int __tracepoint_iter_##name(void *__data, proto)		\
 	{								\
 		struct tracepoint_func *it_func_ptr;			\
 		void *it_func;						\
@@ -307,17 +306,18 @@ static inline struct tracepoint *tracepoint_ptr_deref(tracepoint_ptr_t *p)
 			((void(*)(void *, proto))(it_func))(__data, args); \
 		} while ((++it_func_ptr)->func);			\
 		return 0;						\
-	}
+	}								\
+	DEFINE_STATIC_CALL(__tp_func_##name, __tracepoint_iter_##name);
 
 #define DEFINE_TRACE(name, proto, args)		\
 	DEFINE_TRACE_FN(name, NULL, NULL, PARAMS(proto), PARAMS(args));
 
 #define EXPORT_TRACEPOINT_SYMBOL_GPL(name)				\
 	EXPORT_SYMBOL_GPL(__tracepoint_##name);				\
-	EXPORT_SYMBOL_GPL(__tp_func_##name)
+	EXPORT_STATIC_CALL_GPL(__tp_func_##name)
 #define EXPORT_TRACEPOINT_SYMBOL(name)					\
 	EXPORT_SYMBOL(__tracepoint_##name);				\
-	EXPORT_SYMBOL(__tp_func_##name)
+	EXPORT_STATIC_CALL(__tp_func_##name)
 
 
 #else /* !TRACEPOINTS_ENABLED */
diff --git a/kernel/tracepoint.c b/kernel/tracepoint.c
index 7e1f34edd1d7..4105bdd872f9 100644
--- a/kernel/tracepoint.c
+++ b/kernel/tracepoint.c
@@ -271,10 +271,10 @@ static int tracepoint_add_func(struct tracepoint *tp,
 
 	if (probes == 1) {
 		printk("make direct call to %pS\n", tp_funcs->func);
-		*tp->function_ptr = tp_funcs->func;
+		__static_call_update(tp->static_call_key, tp_funcs->func);
 	} else {
 		printk("[%d] make call to iterator %pS\n", probes, tp->iterator);
-		*tp->function_ptr = tp->iterator;
+		__static_call_update(tp->static_call_key, tp->iterator);
 	}
 
 	release_probes(old);
@@ -312,10 +312,10 @@ static int tracepoint_remove_func(struct tracepoint *tp,
 
 	if (probes_left == 1) {
 		printk("make direct call to %pS\n", tp_funcs->func);
-		*tp->function_ptr = tp_funcs->func;
+		__static_call_update(tp->static_call_key, tp_funcs->func);
 	} else {
 		printk("[%d] make call to iterator %pS\n", probes_left, tp->iterator);
-		*tp->function_ptr = tp->iterator;
+		__static_call_update(tp->static_call_key, tp->iterator);
 	}
 
 	rcu_assign_pointer(tp->funcs, tp_funcs);
-- 
2.19.1


^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 20:08         ` Peter Zijlstra
@ 2018-11-26 21:26           ` Josh Poimboeuf
  2018-11-27  8:43             ` Peter Zijlstra
  0 siblings, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 21:26 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 09:08:01PM +0100, Peter Zijlstra wrote:
> On Mon, Nov 26, 2018 at 11:56:24AM -0600, Josh Poimboeuf wrote:
> > diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> > index d3869295b88d..8fd6c8556750 100644
> > --- a/arch/x86/kernel/static_call.c
> > +++ b/arch/x86/kernel/static_call.c
> > @@ -7,24 +7,19 @@
> >  
> >  #define CALL_INSN_SIZE 5
> >  
> > +unsigned long bp_handler_call_return_addr;
> >  
> > +static void static_call_bp_handler(struct pt_regs *regs)
> > +{
> >  #ifdef CONFIG_HAVE_STATIC_CALL_INLINE
> > +	/*
> > +	 * Push the return address on the stack so the "called" function will
> > +	 * return to immediately after the call site.
> > +	 */
> > +	regs->sp -= sizeof(long);
> > +	*(unsigned long *)regs->sp = bp_handler_call_return_addr;
> >  #endif
> > +}
> >  
> >  void arch_static_call_transform(void *site, void *tramp, void *func)
> >  {
> > @@ -52,14 +47,12 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
> >  	opcodes[0] = insn_opcode;
> >  	memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
> >  
> >  	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> > +		bp_handler_call_return_addr = insn + CALL_INSN_SIZE;
> >  
> >  	/* Patch the call site: */
> >  	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
> > -		     static_call_bp_handler);
> > +		     static_call_bp_handler, func);
> >  
> >  done:
> >  	mutex_unlock(&text_mutex);
> 
> 
> like maybe something along the lines of:
> 
> struct sc_data {
> 	unsigned long ret;
> 	unsigned long ip;
> };
> 
> void sc_handler(struct pt_regs *regs, void *data)
> {
> 	struct sc_data *scd = data;
> 
> 	regs->sp -= sizeof(long);
> 	*(unsigned long *)regs->sp = scd->ret;
> 	regs->ip = scd->ip;
> }
> 
> arch_static_call_transform()
> {
> 	...
> 
> 	scd = (struct sc_data){
> 		.ret = insn + CALL_INSN_SIZE,
> 		.ip = (unsigned long)func,
> 	};
> 
> 	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
> 			sc_handler, (void *)&scd);
> 
> 	...
> }

Yeah, that's probably better.  I assume you also mean that we would have
all text_poke_bp() users create a handler callback?  That way the
interface is clear and consistent for everybody.  Like:

diff --git a/arch/x86/include/asm/text-patching.h b/arch/x86/include/asm/text-patching.h
index e85ff65c43c3..04d6cf838fb7 100644
--- a/arch/x86/include/asm/text-patching.h
+++ b/arch/x86/include/asm/text-patching.h
@@ -20,6 +20,8 @@ static inline void apply_paravirt(struct paravirt_patch_site *start,
 
 extern void *text_poke_early(void *addr, const void *opcode, size_t len);
 
+typedef void (*bp_handler_t)(struct pt_regs *regs, void *data);
+
 /*
  * Clear and restore the kernel write-protection flag on the local CPU.
  * Allows the kernel to edit read-only pages.
@@ -36,7 +38,8 @@ extern void *text_poke_early(void *addr, const void *opcode, size_t len);
  */
 extern void *text_poke(void *addr, const void *opcode, size_t len);
 extern int poke_int3_handler(struct pt_regs *regs);
-extern void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler);
+extern void *text_poke_bp(void *addr, const void *opcode, size_t len,
+			  bp_handler_t handler, void *data);
 extern int after_bootmem;
 
 #endif /* _ASM_X86_TEXT_PATCHING_H */
diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
index ebeac487a20c..547af714bd60 100644
--- a/arch/x86/kernel/alternative.c
+++ b/arch/x86/kernel/alternative.c
@@ -738,7 +738,8 @@ static void do_sync_core(void *info)
 }
 
 static bool bp_patching_in_progress;
-static void *bp_int3_handler, *bp_int3_addr;
+static void *bp_int3_data, *bp_int3_addr;
+static bp_handler_t bp_int3_handler;
 
 int poke_int3_handler(struct pt_regs *regs)
 {
@@ -746,11 +747,11 @@ int poke_int3_handler(struct pt_regs *regs)
 	 * Having observed our INT3 instruction, we now must observe
 	 * bp_patching_in_progress.
 	 *
-	 * 	in_progress = TRUE		INT3
-	 * 	WMB				RMB
-	 * 	write INT3			if (in_progress)
+	 *	in_progress = TRUE		INT3
+	 *	WMB				RMB
+	 *	write INT3			if (in_progress)
 	 *
-	 * Idem for bp_int3_handler.
+	 * Idem for bp_int3_data.
 	 */
 	smp_rmb();
 
@@ -760,8 +761,7 @@ int poke_int3_handler(struct pt_regs *regs)
 	if (user_mode(regs) || regs->ip != (unsigned long)bp_int3_addr)
 		return 0;
 
-	/* set up the specified breakpoint handler */
-	regs->ip = (unsigned long) bp_int3_handler;
+	bp_int3_handler(regs, bp_int3_data);
 
 	return 1;
 
@@ -772,7 +772,8 @@ int poke_int3_handler(struct pt_regs *regs)
  * @addr:	address to patch
  * @opcode:	opcode of new instruction
  * @len:	length to copy
- * @handler:	address to jump to when the temporary breakpoint is hit
+ * @handler:	handler to call from int3 context
+ * @data:	opaque data passed to handler
  *
  * Modify multi-byte instruction by using int3 breakpoint on SMP.
  * We completely avoid stop_machine() here, and achieve the
@@ -787,11 +788,13 @@ int poke_int3_handler(struct pt_regs *regs)
  *	  replacing opcode
  *	- sync cores
  */
-void *text_poke_bp(void *addr, const void *opcode, size_t len, void *handler)
+void *text_poke_bp(void *addr, const void *opcode, size_t len,
+		   bp_handler_t handler, void *data)
 {
 	unsigned char int3 = 0xcc;
 
 	bp_int3_handler = handler;
+	bp_int3_data = data;
 	bp_int3_addr = (u8 *)addr + sizeof(int3);
 	bp_patching_in_progress = true;
 
diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
index aac0c1f7e354..d4b0abe4912d 100644
--- a/arch/x86/kernel/jump_label.c
+++ b/arch/x86/kernel/jump_label.c
@@ -37,6 +37,11 @@ static void bug_at(unsigned char *ip, int line)
 	BUG();
 }
 
+static inline void jump_label_bp_handler(struct pt_regs *regs, void *data)
+{
+	regs->ip += JUMP_LABEL_NOP_SIZE - 1;
+}
+
 static void __ref __jump_label_transform(struct jump_entry *entry,
 					 enum jump_label_type type,
 					 void *(*poker)(void *, const void *, size_t),
@@ -91,7 +96,7 @@ static void __ref __jump_label_transform(struct jump_entry *entry,
 	}
 
 	text_poke_bp((void *)jump_entry_code(entry), code, JUMP_LABEL_NOP_SIZE,
-		     (void *)jump_entry_code(entry) + JUMP_LABEL_NOP_SIZE);
+		     jump_label_bp_handler, NULL);
 }
 
 void arch_jump_label_transform(struct jump_entry *entry,
diff --git a/arch/x86/kernel/kprobes/opt.c b/arch/x86/kernel/kprobes/opt.c
index 40b16b270656..b2dffdd6068d 100644
--- a/arch/x86/kernel/kprobes/opt.c
+++ b/arch/x86/kernel/kprobes/opt.c
@@ -424,6 +424,11 @@ int arch_prepare_optimized_kprobe(struct optimized_kprobe *op,
 	goto out;
 }
 
+static void kprobes_poke_bp_handler(struct pt_regs *regs, void *data)
+{
+	regs->ip = data;
+}
+
 /*
  * Replace breakpoints (int3) with relative jumps.
  * Caller must call with locking kprobe_mutex and text_mutex.
@@ -447,7 +452,7 @@ void arch_optimize_kprobes(struct list_head *oplist)
 		*(s32 *)(&insn_buf[1]) = rel;
 
 		text_poke_bp(op->kp.addr, insn_buf, RELATIVEJUMP_SIZE,
-			     op->optinsn.insn);
+			     kprobes_poke_bp_handler, op->optinsn.insn);
 
 		list_del_init(&op->list);
 	}
@@ -462,7 +467,7 @@ void arch_unoptimize_kprobe(struct optimized_kprobe *op)
 	insn_buf[0] = BREAKPOINT_INSTRUCTION;
 	memcpy(insn_buf + 1, op->optinsn.copied_insn, RELATIVE_ADDR_SIZE);
 	text_poke_bp(op->kp.addr, insn_buf, RELATIVEJUMP_SIZE,
-		     op->optinsn.insn);
+		     kprobes_poke_bp_handler, op->optinsn.insn);
 }
 
 /*
diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
index d3869295b88d..e05ebc6d4db5 100644
--- a/arch/x86/kernel/static_call.c
+++ b/arch/x86/kernel/static_call.c
@@ -7,24 +7,30 @@
 
 #define CALL_INSN_SIZE 5
 
-void static_call_bp_handler(void);
-void *bp_handler_dest;
-void *bp_handler_continue;
-
-asm(".pushsection .text, \"ax\"						\n"
-    ".globl static_call_bp_handler					\n"
-    ".type static_call_bp_handler, @function				\n"
-    "static_call_bp_handler:						\n"
-#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
-    ANNOTATE_RETPOLINE_SAFE
-    "call *bp_handler_dest						\n"
-    ANNOTATE_RETPOLINE_SAFE
-    "jmp *bp_handler_continue						\n"
-#else /* !CONFIG_HAVE_STATIC_CALL_INLINE */
-    ANNOTATE_RETPOLINE_SAFE
-    "jmp *bp_handler_dest						\n"
-#endif
-    ".popsection							\n");
+struct static_call_bp_data {
+	unsigned long func, ret;
+};
+
+static void static_call_bp_handler(struct pt_regs *regs, void *_data)
+{
+	struct static_call_bp_data *data = _data;
+
+	/*
+	 * For inline static calls, push the return address on the stack so the
+	 * "called" function will return to the location immediately after the
+	 * call site.
+	 *
+	 * NOTE: This code will need to be revisited when kernel CET gets
+	 *       implemented.
+	 */
+	if (data->ret) {
+		regs->sp -= sizeof(long);
+		*(unsigned long *)regs->sp = data->ret;
+	}
+
+	/* The exception handler will 'return' to the destination function. */
+	regs->ip = data->func;
+}
 
 void arch_static_call_transform(void *site, void *tramp, void *func)
 {
@@ -32,11 +38,17 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
 	unsigned long insn;
 	unsigned char insn_opcode;
 	unsigned char opcodes[CALL_INSN_SIZE];
+	struct static_call_bp_data handler_data;
+
+	handler_data.func = (unsigned long)func;
 
-	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
+	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE)) {
 		insn = (unsigned long)site;
-	else
+		handler_data.ret = insn + CALL_INSN_SIZE;
+	} else {
 		insn = (unsigned long)tramp;
+		handler_data.ret = 0;
+	}
 
 	mutex_lock(&text_mutex);
 
@@ -52,14 +64,9 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
 	opcodes[0] = insn_opcode;
 	memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
 
-	/* Set up the variables for the breakpoint handler: */
-	bp_handler_dest = func;
-	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
-		bp_handler_continue = (void *)(insn + CALL_INSN_SIZE);
-
 	/* Patch the call site: */
 	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
-		     static_call_bp_handler);
+		     static_call_bp_handler, &handler_data);
 
 done:
 	mutex_unlock(&text_mutex);

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-11-26 20:54 ` Steven Rostedt
@ 2018-11-26 22:24   ` Josh Poimboeuf
  2018-11-26 22:53     ` Steven Rostedt
  0 siblings, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-26 22:24 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Peter Zijlstra, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 03:54:05PM -0500, Steven Rostedt wrote:
> In summary, we had this:
> 
> No RETPOLINES:
>             1.4503 +- 0.0148 seconds time elapsed  ( +-  1.02% )
> 
> baseline RETPOLINES:
>             1.5120 +- 0.0133 seconds time elapsed  ( +-  0.88% )
> 
> Added direct calls for trace_events:
>             1.5239 +- 0.0139 seconds time elapsed  ( +-  0.91% )
> 
> With static calls:
>             1.5282 +- 0.0135 seconds time elapsed  ( +-  0.88% )
> 
> With static call trampolines:
>            1.48328 +- 0.00515 seconds time elapsed  ( +-  0.35% )
> 
> Full static calls:
>            1.47364 +- 0.00706 seconds time elapsed  ( +-  0.48% )
> 
> 
> Adding Retpolines caused a 1.5120 / 1.4503 = 1.0425 ( 4.25% ) slowdown
> 
> Trampolines made it into 1.48328 / 1.4503 = 1.0227 ( 2.27% ) slowdown
> 
> With full static calls 1.47364 / 1.4503 = 1.0160 ( 1.6% ) slowdown
> 
> Going from 4.25 to 1.6 isn't bad, and I think this is very much worth
> the effort. I did not expect it to go to 0% as there's a lot of other
> places that retpolines cause issues, but this shows that it does help
> the tracing code.
> 
> I originally did the tests with the development config, which has a
> bunch of debugging options enabled (hackbench usually takes over 9
> seconds, not the 1.5 that was done here), and the slowdown was closer
> to 9% with retpolines. If people want me to do this with that, or I can
> send them the config. Or better yet, the code is here, just use your
> own configs.

Thanks a lot for running these.  This looks like a nice speedup.  Also a
nice reduction in the standard deviation.

Should I add your tracepoint patch to the next version of my patches?

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-11-26 22:24   ` Josh Poimboeuf
@ 2018-11-26 22:53     ` Steven Rostedt
  0 siblings, 0 replies; 120+ messages in thread
From: Steven Rostedt @ 2018-11-26 22:53 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Peter Zijlstra, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, 26 Nov 2018 16:24:20 -0600
Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> Should I add your tracepoint patch to the next version of my patches?
> 

No, not yet. Especially since I haven't totally vetted them.

When yours are ready, I'll post an RFC, and then we can add them in. I
would want an Acked-by from Mathieu Desnoyers too.

-- Steve


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 21:26           ` Josh Poimboeuf
@ 2018-11-27  8:43             ` Peter Zijlstra
  2018-11-27  8:50               ` Peter Zijlstra
  2018-11-29  6:05               ` Andy Lutomirski
  0 siblings, 2 replies; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-27  8:43 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Mon, Nov 26, 2018 at 03:26:28PM -0600, Josh Poimboeuf wrote:

> Yeah, that's probably better.  I assume you also mean that we would have
> all text_poke_bp() users create a handler callback?  That way the
> interface is clear and consistent for everybody.  Like:

Can do, it does indeed make the interface less like a hack. It is not
like there are too many users.

> diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
> index aac0c1f7e354..d4b0abe4912d 100644
> --- a/arch/x86/kernel/jump_label.c
> +++ b/arch/x86/kernel/jump_label.c
> @@ -37,6 +37,11 @@ static void bug_at(unsigned char *ip, int line)
>  	BUG();
>  }
>  
> +static inline void jump_label_bp_handler(struct pt_regs *regs, void *data)
> +{
> +	regs->ip += JUMP_LABEL_NOP_SIZE - 1;
> +}
> +
>  static void __ref __jump_label_transform(struct jump_entry *entry,
>  					 enum jump_label_type type,
>  					 void *(*poker)(void *, const void *, size_t),
> @@ -91,7 +96,7 @@ static void __ref __jump_label_transform(struct jump_entry *entry,
>  	}
>  
>  	text_poke_bp((void *)jump_entry_code(entry), code, JUMP_LABEL_NOP_SIZE,
> -		     (void *)jump_entry_code(entry) + JUMP_LABEL_NOP_SIZE);
> +		     jump_label_bp_handler, NULL);
>  }
>  
>  void arch_jump_label_transform(struct jump_entry *entry,

Per that example..

> diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
> index d3869295b88d..e05ebc6d4db5 100644
> --- a/arch/x86/kernel/static_call.c
> +++ b/arch/x86/kernel/static_call.c
> @@ -7,24 +7,30 @@
>  
>  #define CALL_INSN_SIZE 5
>  
> +struct static_call_bp_data {
> +	unsigned long func, ret;
> +};
> +
> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
> +{
> +	struct static_call_bp_data *data = _data;
> +
> +	/*
> +	 * For inline static calls, push the return address on the stack so the
> +	 * "called" function will return to the location immediately after the
> +	 * call site.
> +	 *
> +	 * NOTE: This code will need to be revisited when kernel CET gets
> +	 *       implemented.
> +	 */
> +	if (data->ret) {
> +		regs->sp -= sizeof(long);
> +		*(unsigned long *)regs->sp = data->ret;
> +	}
> +
> +	/* The exception handler will 'return' to the destination function. */
> +	regs->ip = data->func;
> +}

Now; if I'm not mistaken, the below @site is in fact @regs->ip - 1, no?

We already patched site with INT3, which is what we just trapped on. So
we could in fact write something like:

static void static_call_bp_handler(struct pt_regs *regs, void *data)
{
	struct static_call_bp_data *scd = data;

	switch (data->type) {
	case CALL_INSN: /* emulate CALL instruction */
		regs->sp -= sizeof(unsigned long);
		*(unsigned long *)regs->sp = regs->ip + CALL_INSN_SIZE - 1;
		regs->ip = data->func;
		break;

	case JMP_INSN: /* emulate JMP instruction */
		regs->ip = data->func;
		break;
	}
}

>  void arch_static_call_transform(void *site, void *tramp, void *func)
>  {
> @@ -32,11 +38,17 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
>  	unsigned long insn;
>  	unsigned char insn_opcode;
>  	unsigned char opcodes[CALL_INSN_SIZE];
> +	struct static_call_bp_data handler_data;
> +
> +	handler_data.func = (unsigned long)func;
>  
> -	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE))
> +	if (IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE)) {
>  		insn = (unsigned long)site;
> +		handler_data.ret = insn + CALL_INSN_SIZE;
> +	} else {
>  		insn = (unsigned long)tramp;
> +		handler_data.ret = 0;
> +	}

	handler_data = (struct static_call_bp_data){
		.type = IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE) ? CALL_INSN : JMP_INSN,
		.func = func,
	};

>  	mutex_lock(&text_mutex);
>  
> @@ -52,14 +64,9 @@ void arch_static_call_transform(void *site, void *tramp, void *func)
>  	opcodes[0] = insn_opcode;
>  	memcpy(&opcodes[1], &dest_relative, CALL_INSN_SIZE - 1);
>  
>  	/* Patch the call site: */
>  	text_poke_bp((void *)insn, opcodes, CALL_INSN_SIZE,
> +		     static_call_bp_handler, &handler_data);
>  
>  done:
>  	mutex_unlock(&text_mutex);

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-26 20:14         ` Josh Poimboeuf
@ 2018-11-27  8:46           ` Peter Zijlstra
  0 siblings, 0 replies; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-27  8:46 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Andy Lutomirski, X86 ML, LKML, Ard Biesheuvel, Steven Rostedt,
	Ingo Molnar, Thomas Gleixner, Linus Torvalds, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	jeyu, H. Peter Anvin

On Mon, Nov 26, 2018 at 02:14:49PM -0600, Josh Poimboeuf wrote:
> On Mon, Nov 26, 2018 at 10:28:08AM -0800, Andy Lutomirski wrote:

> > Can you add a comment that it will need updating when kernel CET is added?
> 
> Will do, though I get the feeling there's a lot of other (existing) code
> that will also need to change for kernel CET.

Yeah, function graph tracer and kretprobes at the very least. But I
suspect there's a few surprises to be hand once they try kernel CET.


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 1/4] compiler.h: Make __ADDRESSABLE() symbol truly unique
  2018-11-26 13:54 ` [PATCH v2 1/4] compiler.h: Make __ADDRESSABLE() symbol truly unique Josh Poimboeuf
@ 2018-11-27  8:49   ` Ard Biesheuvel
  0 siblings, 0 replies; 120+ messages in thread
From: Ard Biesheuvel @ 2018-11-27  8:49 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: the arch/x86 maintainers, Linux Kernel Mailing List,
	Andy Lutomirski, Steven Rostedt, Peter Zijlstra, Ingo Molnar,
	Thomas Gleixner, Linus Torvalds, Masami Hiramatsu, Jason Baron,
	Jiri Kosina, David Laight, Borislav Petkov, julia, Jessica Yu,
	H. Peter Anvin

On Mon, 26 Nov 2018 at 14:55, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> The __ADDRESSABLE() macro uses the __LINE__ macro to create a temporary
> symbol which has a unique name.  However, if the macro is used multiple
> times from within another macro, the line number will always be the
> same, resulting in duplicate symbols.
>
> Make the temporary symbols truly unique by using __UNIQUE_ID instead of
> __LINE__.
>
> Signed-off-by: Josh Poimboeuf <jpoimboe@redhat.com>

Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>

> ---
>  include/linux/compiler.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/compiler.h b/include/linux/compiler.h
> index 06396c1cf127..4bb73fd918b5 100644
> --- a/include/linux/compiler.h
> +++ b/include/linux/compiler.h
> @@ -282,7 +282,7 @@ unsigned long read_word_at_a_time(const void *addr)
>   */
>  #define __ADDRESSABLE(sym) \
>         static void * __section(".discard.addressable") __used \
> -               __PASTE(__addressable_##sym, __LINE__) = (void *)&sym;
> +               __UNIQUE_ID(__addressable_##sym) = (void *)&sym;
>
>  /**
>   * offset_to_ptr - convert a relative memory offset to an absolute pointer
> --
> 2.17.2
>

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-27  8:43             ` Peter Zijlstra
@ 2018-11-27  8:50               ` Peter Zijlstra
  2018-11-29  6:05               ` Andy Lutomirski
  1 sibling, 0 replies; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-27  8:50 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin

On Tue, Nov 27, 2018 at 09:43:30AM +0100, Peter Zijlstra wrote:
> Now; if I'm not mistaken, the below @site is in fact @regs->ip - 1, no?
> 
> We already patched site with INT3, which is what we just trapped on. So
> we could in fact write something like:
> 
> static void static_call_bp_handler(struct pt_regs *regs, void *data)
> {
> 	struct static_call_bp_data *scd = data;
> 
> 	switch (data->type) {
> 	case CALL_INSN: /* emulate CALL instruction */
> 		regs->sp -= sizeof(unsigned long);
> 		*(unsigned long *)regs->sp = regs->ip + CALL_INSN_SIZE - 1;
> 		regs->ip = data->func;
> 		break;
> 
> 	case JMP_INSN: /* emulate JMP instruction */
> 		regs->ip = data->func;
> 		break;
> 	}
> }

> 	handler_data = (struct static_call_bp_data){
> 		.type = IS_ENABLED(CONFIG_HAVE_STATIC_CALL_INLINE) ? CALL_INSN : JMP_INSN,
> 		.func = func,
> 	};

Heck; check this:

static void static_call_bp_handler(struct pt_regs *regs, void *data)
{
#ifdef CONFIG_HAVE_STATIC_CALL_INLINE

	/* emulate CALL instruction */
	regs->sp -= sizeof(unsigned long);
	*(unsigned long *)regs->sp = regs->ip + CALL_INSN_SIZE - 1;
	regs->ip = data;

#else /* !CONFIG_HAVE_STATIC_CALL_INLINE */

	/* emulate JMP instruction */
	regs->ip = data;

#endif
}



^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-27  8:43             ` Peter Zijlstra
  2018-11-27  8:50               ` Peter Zijlstra
@ 2018-11-29  6:05               ` Andy Lutomirski
  2018-11-29  9:42                 ` Peter Zijlstra
  1 sibling, 1 reply; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29  6:05 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Josh Poimboeuf, X86 ML, LKML, Ard Biesheuvel, Andrew Lutomirski,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

> On Nov 27, 2018, at 12:43 AM, Peter Zijlstra <peterz@infradead.org> wrote:
>
>> On Mon, Nov 26, 2018 at 03:26:28PM -0600, Josh Poimboeuf wrote:
>>
>> Yeah, that's probably better.  I assume you also mean that we would have
>> all text_poke_bp() users create a handler callback?  That way the
>> interface is clear and consistent for everybody.  Like:
>
> Can do, it does indeed make the interface less like a hack. It is not
> like there are too many users.
>
>> diff --git a/arch/x86/kernel/jump_label.c b/arch/x86/kernel/jump_label.c
>> index aac0c1f7e354..d4b0abe4912d 100644
>> --- a/arch/x86/kernel/jump_label.c
>> +++ b/arch/x86/kernel/jump_label.c
>> @@ -37,6 +37,11 @@ static void bug_at(unsigned char *ip, int line)
>>    BUG();
>> }
>>
>> +static inline void jump_label_bp_handler(struct pt_regs *regs, void *data)
>> +{
>> +    regs->ip += JUMP_LABEL_NOP_SIZE - 1;
>> +}
>> +
>> static void __ref __jump_label_transform(struct jump_entry *entry,
>>                     enum jump_label_type type,
>>                     void *(*poker)(void *, const void *, size_t),
>> @@ -91,7 +96,7 @@ static void __ref __jump_label_transform(struct jump_entry *entry,
>>    }
>>
>>    text_poke_bp((void *)jump_entry_code(entry), code, JUMP_LABEL_NOP_SIZE,
>> -             (void *)jump_entry_code(entry) + JUMP_LABEL_NOP_SIZE);
>> +             jump_label_bp_handler, NULL);
>> }
>>
>> void arch_jump_label_transform(struct jump_entry *entry,
>
> Per that example..
>
>> diff --git a/arch/x86/kernel/static_call.c b/arch/x86/kernel/static_call.c
>> index d3869295b88d..e05ebc6d4db5 100644
>> --- a/arch/x86/kernel/static_call.c
>> +++ b/arch/x86/kernel/static_call.c
>> @@ -7,24 +7,30 @@
>>
>> #define CALL_INSN_SIZE 5
>>
>> +struct static_call_bp_data {
>> +    unsigned long func, ret;
>> +};
>> +
>> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
>> +{
>> +    struct static_call_bp_data *data = _data;
>> +
>> +    /*
>> +     * For inline static calls, push the return address on the stack so the
>> +     * "called" function will return to the location immediately after the
>> +     * call site.
>> +     *
>> +     * NOTE: This code will need to be revisited when kernel CET gets
>> +     *       implemented.
>> +     */
>> +    if (data->ret) {
>> +        regs->sp -= sizeof(long);
>> +        *(unsigned long *)regs->sp = data->ret;
>> +    }

You can’t do this.  Depending on the alignment of the old RSP, which
is not guaranteed, this overwrites regs->cs.  IRET goes boom.

Maybe it could be fixed by pointing regs->ip at a real trampoline?

This code is subtle and executed rarely, which is a bag combination.
It would be great if we had a test case.

I think it would be great if the implementation could be, literally:

regs->ip -= 1;
return;

IOW, just retry and wait until we get the new patched instruction.
The problem is that, if we're in a context where IRQs are off, then
we're preventing on_each_cpu() from completing and, even if we somehow
just let the code know that we already serialized ourselves, we're
still potentially holding a spinlock that another CPU is waiting for
with IRQs off.  Ugh.  Anyone have a clever idea to fix that?

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29  6:05               ` Andy Lutomirski
@ 2018-11-29  9:42                 ` Peter Zijlstra
  2018-11-29 13:11                   ` Josh Poimboeuf
  2018-11-29 13:37                   ` Andy Lutomirski
  0 siblings, 2 replies; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-29  9:42 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Josh Poimboeuf, X86 ML, LKML, Ard Biesheuvel, Steven Rostedt,
	Ingo Molnar, Thomas Gleixner, Linus Torvalds, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	jeyu, H. Peter Anvin

On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote:

> >> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
> >> +{
> >> +    struct static_call_bp_data *data = _data;
> >> +
> >> +    /*
> >> +     * For inline static calls, push the return address on the stack so the
> >> +     * "called" function will return to the location immediately after the
> >> +     * call site.
> >> +     *
> >> +     * NOTE: This code will need to be revisited when kernel CET gets
> >> +     *       implemented.
> >> +     */
> >> +    if (data->ret) {
> >> +        regs->sp -= sizeof(long);
> >> +        *(unsigned long *)regs->sp = data->ret;
> >> +    }
> 
> You can’t do this.  Depending on the alignment of the old RSP, which
> is not guaranteed, this overwrites regs->cs.  IRET goes boom.

I don't get it; can you spell that out?

The way I understand it is that we're at a location where a "E8 - Near
CALL" instruction should be, and thus RSP should be the regular kernel
stack, and the above simply does "PUSH ret", which is what that CALL
would've done too.



^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29  9:42                 ` Peter Zijlstra
@ 2018-11-29 13:11                   ` Josh Poimboeuf
  2018-11-29 13:37                   ` Andy Lutomirski
  1 sibling, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-29 13:11 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Andy Lutomirski, X86 ML, LKML, Ard Biesheuvel, Steven Rostedt,
	Ingo Molnar, Thomas Gleixner, Linus Torvalds, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 10:42:10AM +0100, Peter Zijlstra wrote:
> On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote:
> 
> > >> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
> > >> +{
> > >> +    struct static_call_bp_data *data = _data;
> > >> +
> > >> +    /*
> > >> +     * For inline static calls, push the return address on the stack so the
> > >> +     * "called" function will return to the location immediately after the
> > >> +     * call site.
> > >> +     *
> > >> +     * NOTE: This code will need to be revisited when kernel CET gets
> > >> +     *       implemented.
> > >> +     */
> > >> +    if (data->ret) {
> > >> +        regs->sp -= sizeof(long);
> > >> +        *(unsigned long *)regs->sp = data->ret;
> > >> +    }
> > 
> > You can’t do this.  Depending on the alignment of the old RSP, which
> > is not guaranteed, this overwrites regs->cs.  IRET goes boom.
> 
> I don't get it; can you spell that out?

I don't quite follow that either.  Maybe Andy is referring to x86-32,
for which regs->sp isn't actually saved: see kernel_stack_pointer().

This code is 64-bit only so that's not a concern.

> The way I understand it is that we're at a location where a "E8 - Near
> CALL" instruction should be, and thus RSP should be the regular kernel
> stack, and the above simply does "PUSH ret", which is what that CALL
> would've done too.

Right.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29  9:42                 ` Peter Zijlstra
  2018-11-29 13:11                   ` Josh Poimboeuf
@ 2018-11-29 13:37                   ` Andy Lutomirski
  2018-11-29 14:38                     ` Peter Zijlstra
  1 sibling, 1 reply; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29 13:37 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Andy Lutomirski, Josh Poimboeuf, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin



> On Nov 29, 2018, at 1:42 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote:
> 
>>>> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
>>>> +{
>>>> +    struct static_call_bp_data *data = _data;
>>>> +
>>>> +    /*
>>>> +     * For inline static calls, push the return address on the stack so the
>>>> +     * "called" function will return to the location immediately after the
>>>> +     * call site.
>>>> +     *
>>>> +     * NOTE: This code will need to be revisited when kernel CET gets
>>>> +     *       implemented.
>>>> +     */
>>>> +    if (data->ret) {
>>>> +        regs->sp -= sizeof(long);
>>>> +        *(unsigned long *)regs->sp = data->ret;
>>>> +    }
>> 
>> You can’t do this.  Depending on the alignment of the old RSP, which
>> is not guaranteed, this overwrites regs->cs.  IRET goes boom.
> 
> I don't get it; can you spell that out?
> 
> The way I understand it is that we're at a location where a "E8 - Near
> CALL" instruction should be, and thus RSP should be the regular kernel
> stack, and the above simply does "PUSH ret", which is what that CALL
> would've done too.
> 

int3 isn’t IST anymore, so the int3 instruction conditionally subtracts 8 from RSP and then pushes SS, etc. So my email was obviously wrong wrt “cs”, but you’re still potentially overwriting the int3 IRET frame.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 13:37                   ` Andy Lutomirski
@ 2018-11-29 14:38                     ` Peter Zijlstra
  2018-11-29 14:42                       ` Jiri Kosina
  2018-11-29 16:33                       ` Josh Poimboeuf
  0 siblings, 2 replies; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-29 14:38 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Andy Lutomirski, Josh Poimboeuf, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 05:37:39AM -0800, Andy Lutomirski wrote:
> 
> 
> > On Nov 29, 2018, at 1:42 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote:
> > 
> >>>> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
> >>>> +{
> >>>> +    struct static_call_bp_data *data = _data;
> >>>> +
> >>>> +    /*
> >>>> +     * For inline static calls, push the return address on the stack so the
> >>>> +     * "called" function will return to the location immediately after the
> >>>> +     * call site.
> >>>> +     *
> >>>> +     * NOTE: This code will need to be revisited when kernel CET gets
> >>>> +     *       implemented.
> >>>> +     */
> >>>> +    if (data->ret) {
> >>>> +        regs->sp -= sizeof(long);
> >>>> +        *(unsigned long *)regs->sp = data->ret;
> >>>> +    }
> >> 
> >> You can’t do this.  Depending on the alignment of the old RSP, which
> >> is not guaranteed, this overwrites regs->cs.  IRET goes boom.
> > 
> > I don't get it; can you spell that out?
> > 
> > The way I understand it is that we're at a location where a "E8 - Near
> > CALL" instruction should be, and thus RSP should be the regular kernel
> > stack, and the above simply does "PUSH ret", which is what that CALL
> > would've done too.
> > 
> 
> int3 isn’t IST anymore, so the int3 instruction conditionally
> subtracts 8 from RSP and then pushes SS, etc. So my email was
> obviously wrong wrt “cs”, but you’re still potentially overwriting the
> int3 IRET frame.

ARGH!..

can't we 'fix' that again? The alternative is moving that IRET-frame and
fixing everything up, which is going to be fragile, ugly and such
things more.

Commit d8ba61ba58c8 ("x86/entry/64: Don't use IST entry for #BP stack")
doesn't list any strong reasons for why it should NOT be an IST.



^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 14:38                     ` Peter Zijlstra
@ 2018-11-29 14:42                       ` Jiri Kosina
  2018-11-29 16:33                       ` Josh Poimboeuf
  1 sibling, 0 replies; 120+ messages in thread
From: Jiri Kosina @ 2018-11-29 14:42 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Andy Lutomirski, Andy Lutomirski, Josh Poimboeuf, X86 ML, LKML,
	Ard Biesheuvel, Steven Rostedt, Ingo Molnar, Thomas Gleixner,
	Linus Torvalds, Masami Hiramatsu, Jason Baron, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, 29 Nov 2018, Peter Zijlstra wrote:

> > int3 isn’t IST anymore, so the int3 instruction conditionally 
> > subtracts 8 from RSP and then pushes SS, etc. So my email was 
> > obviously wrong wrt “cs”, but you’re still potentially overwriting the 
> > int3 IRET frame.
> 
> ARGH!..
> 
> can't we 'fix' that again? The alternative is moving that IRET-frame and
> fixing everything up, which is going to be fragile, ugly and such
> things more.
> 
> Commit d8ba61ba58c8 ("x86/entry/64: Don't use IST entry for #BP stack")
> doesn't list any strong reasons for why it should NOT be an IST.

It's CVE-2018-8897.

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 14:38                     ` Peter Zijlstra
  2018-11-29 14:42                       ` Jiri Kosina
@ 2018-11-29 16:33                       ` Josh Poimboeuf
  2018-11-29 16:49                         ` Peter Zijlstra
  2018-11-29 16:50                         ` Linus Torvalds
  1 sibling, 2 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-29 16:33 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Andy Lutomirski, Andy Lutomirski, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 03:38:53PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 05:37:39AM -0800, Andy Lutomirski wrote:
> > 
> > 
> > > On Nov 29, 2018, at 1:42 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > > 
> > > On Wed, Nov 28, 2018 at 10:05:54PM -0800, Andy Lutomirski wrote:
> > > 
> > >>>> +static void static_call_bp_handler(struct pt_regs *regs, void *_data)
> > >>>> +{
> > >>>> +    struct static_call_bp_data *data = _data;
> > >>>> +
> > >>>> +    /*
> > >>>> +     * For inline static calls, push the return address on the stack so the
> > >>>> +     * "called" function will return to the location immediately after the
> > >>>> +     * call site.
> > >>>> +     *
> > >>>> +     * NOTE: This code will need to be revisited when kernel CET gets
> > >>>> +     *       implemented.
> > >>>> +     */
> > >>>> +    if (data->ret) {
> > >>>> +        regs->sp -= sizeof(long);
> > >>>> +        *(unsigned long *)regs->sp = data->ret;
> > >>>> +    }
> > >> 
> > >> You can’t do this.  Depending on the alignment of the old RSP, which
> > >> is not guaranteed, this overwrites regs->cs.  IRET goes boom.
> > > 
> > > I don't get it; can you spell that out?
> > > 
> > > The way I understand it is that we're at a location where a "E8 - Near
> > > CALL" instruction should be, and thus RSP should be the regular kernel
> > > stack, and the above simply does "PUSH ret", which is what that CALL
> > > would've done too.
> > > 
> > 
> > int3 isn’t IST anymore, so the int3 instruction conditionally
> > subtracts 8 from RSP and then pushes SS, etc. So my email was
> > obviously wrong wrt “cs”, but you’re still potentially overwriting the
> > int3 IRET frame.
> 
> ARGH!..
> 
> can't we 'fix' that again? The alternative is moving that IRET-frame and
> fixing everything up, which is going to be fragile, ugly and such
> things more.
> 
> Commit d8ba61ba58c8 ("x86/entry/64: Don't use IST entry for #BP stack")
> doesn't list any strong reasons for why it should NOT be an IST.

This seems to work...

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index ce25d84023c0..184523447d35 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -876,7 +876,7 @@ apicinterrupt IRQ_WORK_VECTOR			irq_work_interrupt		smp_irq_work_interrupt
  * @paranoid == 2 is special: the stub will never switch stacks.  This is for
  * #DF: if the thread stack is somehow unusable, we'll still get a useful OOPS.
  */
-.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
+.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 create_gap=0
 ENTRY(\sym)
 	UNWIND_HINT_IRET_REGS offset=\has_error_code*8
 
@@ -891,6 +891,12 @@ ENTRY(\sym)
 	pushq	$-1				/* ORIG_RAX: no syscall to restart */
 	.endif
 
+	.if \create_gap == 1
+	.rept 6
+	pushq 5*8(%rsp)
+	.endr
+	.endif
+
 	.if \paranoid == 1
 	testb	$3, CS-ORIG_RAX(%rsp)		/* If coming from userspace, switch stacks */
 	jnz	.Lfrom_usermode_switch_stack_\@
@@ -1126,7 +1132,7 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \
 #endif /* CONFIG_HYPERV */
 
 idtentry debug			do_debug		has_error_code=0	paranoid=1 shift_ist=DEBUG_STACK
-idtentry int3			do_int3			has_error_code=0
+idtentry int3			do_int3			has_error_code=0	create_gap=1
 idtentry stack_segment		do_stack_segment	has_error_code=1
 
 #ifdef CONFIG_XEN_PV

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 16:33                       ` Josh Poimboeuf
@ 2018-11-29 16:49                         ` Peter Zijlstra
  2018-11-29 16:59                           ` Andy Lutomirski
  2018-11-29 16:50                         ` Linus Torvalds
  1 sibling, 1 reply; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-29 16:49 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Andy Lutomirski, Andy Lutomirski, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 10:33:42AM -0600, Josh Poimboeuf wrote:
> > can't we 'fix' that again? The alternative is moving that IRET-frame and
> > fixing everything up, which is going to be fragile, ugly and such
> > things more.

> This seems to work...

That's almost too easy... nice!

> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
> index ce25d84023c0..184523447d35 100644
> --- a/arch/x86/entry/entry_64.S
> +++ b/arch/x86/entry/entry_64.S
> @@ -876,7 +876,7 @@ apicinterrupt IRQ_WORK_VECTOR			irq_work_interrupt		smp_irq_work_interrupt
>   * @paranoid == 2 is special: the stub will never switch stacks.  This is for
>   * #DF: if the thread stack is somehow unusable, we'll still get a useful OOPS.
>   */
> -.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
> +.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 create_gap=0
>  ENTRY(\sym)
>  	UNWIND_HINT_IRET_REGS offset=\has_error_code*8
>  
> @@ -891,6 +891,12 @@ ENTRY(\sym)
>  	pushq	$-1				/* ORIG_RAX: no syscall to restart */
>  	.endif
>  
> +	.if \create_gap == 1
> +	.rept 6
> +	pushq 5*8(%rsp)
> +	.endr
> +	.endif
> +
>  	.if \paranoid == 1
>  	testb	$3, CS-ORIG_RAX(%rsp)		/* If coming from userspace, switch stacks */
>  	jnz	.Lfrom_usermode_switch_stack_\@
> @@ -1126,7 +1132,7 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \
>  #endif /* CONFIG_HYPERV */
>  
>  idtentry debug			do_debug		has_error_code=0	paranoid=1 shift_ist=DEBUG_STACK
> -idtentry int3			do_int3			has_error_code=0
> +idtentry int3			do_int3			has_error_code=0	create_gap=1
>  idtentry stack_segment		do_stack_segment	has_error_code=1
>  
>  #ifdef CONFIG_XEN_PV

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 16:33                       ` Josh Poimboeuf
  2018-11-29 16:49                         ` Peter Zijlstra
@ 2018-11-29 16:50                         ` Linus Torvalds
  2018-11-29 16:55                           ` Steven Rostedt
  2018-11-29 17:02                           ` Andy Lutomirski
  1 sibling, 2 replies; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 16:50 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Peter Zijlstra, Andy Lutomirski, Andrew Lutomirski,
	the arch/x86 maintainers, Linux List Kernel Mailing,
	Ard Biesheuvel, Steven Rostedt, Ingo Molnar, Thomas Gleixner,
	mhiramat, jbaron, Jiri Kosina, David.Laight, bp, julia, jeyu,
	Peter Anvin

On Thu, Nov 29, 2018 at 8:33 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> This seems to work...
>
> +       .if \create_gap == 1
> +       .rept 6
> +       pushq 5*8(%rsp)
> +       .endr
> +       .endif
> +
> -idtentry int3                  do_int3                 has_error_code=0
> +idtentry int3                  do_int3                 has_error_code=0        create_gap=1

Ugh. Doesn't this entirely screw up the stack layout, which then
screws up  task_pt_regs(), which then breaks ptrace and friends?

... and you'd only notice it for users that use int3 in user space,
which now writes random locations on the kernel stack, which is then a
huge honking security hole.

It's possible that I'm confused, but let's not play random games with
the stack like this. The entry code is sacred, in scary ways.

So no. Do *not* try to change %rsp on the stack in the bp handler.
Instead, I'd suggest:

 - just restart the instruction (with the suggested "ptregs->rip --")

 - to avoid any "oh, we're not making progress" issues, just fix the
instruction yourself to be the right call, by looking it up in the
"what needs to be fixed" tables.

No?

              Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 16:50                         ` Linus Torvalds
@ 2018-11-29 16:55                           ` Steven Rostedt
  2018-11-29 17:02                           ` Andy Lutomirski
  1 sibling, 0 replies; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 16:55 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Josh Poimboeuf, Peter Zijlstra, Andy Lutomirski,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, 29 Nov 2018 08:50:16 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> Instead, I'd suggest:
> 
>  - just restart the instruction (with the suggested "ptregs->rip --")
> 
>  - to avoid any "oh, we're not making progress" issues, just fix the
> instruction yourself to be the right call, by looking it up in the
> "what needs to be fixed" tables.

So basically this will cause the code to go into a spin while we are
doing the update, right?

-- Steve

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 16:49                         ` Peter Zijlstra
@ 2018-11-29 16:59                           ` Andy Lutomirski
  2018-11-29 17:10                             ` Josh Poimboeuf
  2018-11-29 17:15                             ` Peter Zijlstra
  0 siblings, 2 replies; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29 16:59 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Josh Poimboeuf, Andy Lutomirski, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin



> On Nov 29, 2018, at 8:49 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> On Thu, Nov 29, 2018 at 10:33:42AM -0600, Josh Poimboeuf wrote:
>>> can't we 'fix' that again? The alternative is moving that IRET-frame and
>>> fixing everything up, which is going to be fragile, ugly and such
>>> things more.
> 
>> This seems to work...
> 
> That's almost too easy... nice!

It is indeed too easy: you’re putting pt_regs in the wrong place for int3 from user mode, which is probably a root hole if you arrange for a ptraced process to do int3 and try to write to whatever register aliases CS.

If you make it conditional on CPL, do it for 32-bit as well, add comments, and convince yourself that there isn’t a better solution (like pointing IP at a stub that retpolines to the target by reading the function pointer, a la the unoptimizable version), then okay, I guess, with only a small amount of grumbling.

> 
>> diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
>> index ce25d84023c0..184523447d35 100644
>> --- a/arch/x86/entry/entry_64.S
>> +++ b/arch/x86/entry/entry_64.S
>> @@ -876,7 +876,7 @@ apicinterrupt IRQ_WORK_VECTOR            irq_work_interrupt        smp_irq_work_interrupt
>>  * @paranoid == 2 is special: the stub will never switch stacks.  This is for
>>  * #DF: if the thread stack is somehow unusable, we'll still get a useful OOPS.
>>  */
>> -.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
>> +.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 create_gap=0
>> ENTRY(\sym)
>>    UNWIND_HINT_IRET_REGS offset=\has_error_code*8
>> 
>> @@ -891,6 +891,12 @@ ENTRY(\sym)
>>    pushq    $-1                /* ORIG_RAX: no syscall to restart */
>>    .endif
>> 
>> +    .if \create_gap == 1
>> +    .rept 6
>> +    pushq 5*8(%rsp)
>> +    .endr
>> +    .endif
>> +
>>    .if \paranoid == 1
>>    testb    $3, CS-ORIG_RAX(%rsp)        /* If coming from userspace, switch stacks */
>>    jnz    .Lfrom_usermode_switch_stack_\@
>> @@ -1126,7 +1132,7 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \
>> #endif /* CONFIG_HYPERV */
>> 
>> idtentry debug            do_debug        has_error_code=0    paranoid=1 shift_ist=DEBUG_STACK
>> -idtentry int3            do_int3            has_error_code=0
>> +idtentry int3            do_int3            has_error_code=0    create_gap=1
>> idtentry stack_segment        do_stack_segment    has_error_code=1
>> 
>> #ifdef CONFIG_XEN_PV

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 16:50                         ` Linus Torvalds
  2018-11-29 16:55                           ` Steven Rostedt
@ 2018-11-29 17:02                           ` Andy Lutomirski
  2018-11-29 17:07                             ` Peter Zijlstra
                                               ` (2 more replies)
  1 sibling, 3 replies; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29 17:02 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Josh Poimboeuf, Peter Zijlstra, Andrew Lutomirski,
	the arch/x86 maintainers, Linux List Kernel Mailing,
	Ard Biesheuvel, Steven Rostedt, Ingo Molnar, Thomas Gleixner,
	mhiramat, jbaron, Jiri Kosina, David.Laight, bp, julia, jeyu,
	Peter Anvin



> On Nov 29, 2018, at 8:50 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
>> On Thu, Nov 29, 2018 at 8:33 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>> 
>> This seems to work...
>> 
>> +       .if \create_gap == 1
>> +       .rept 6
>> +       pushq 5*8(%rsp)
>> +       .endr
>> +       .endif
>> +
>> -idtentry int3                  do_int3                 has_error_code=0
>> +idtentry int3                  do_int3                 has_error_code=0        create_gap=1
> 
> Ugh. Doesn't this entirely screw up the stack layout, which then
> screws up  task_pt_regs(), which then breaks ptrace and friends?
> 
> ... and you'd only notice it for users that use int3 in user space,
> which now writes random locations on the kernel stack, which is then a
> huge honking security hole.
> 
> It's possible that I'm confused, but let's not play random games with
> the stack like this. The entry code is sacred, in scary ways.
> 
> So no. Do *not* try to change %rsp on the stack in the bp handler.
> Instead, I'd suggest:
> 
> - just restart the instruction (with the suggested "ptregs->rip --")
> 
> - to avoid any "oh, we're not making progress" issues, just fix the
> instruction yourself to be the right call, by looking it up in the
> "what needs to be fixed" tables.
> 
> No?

I thought that too.  I think it deadlocks. CPU A does text_poke_bp().  CPU B is waiting for a spinlock with IRQs off.  CPU C holds the spinlock and hits the int3.  The int3 never goes away because CPU A is waiting for CPU B to handle the sync_core IPI.

Or do you think we can avoid the IPI while the int3 is there?

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:02                           ` Andy Lutomirski
@ 2018-11-29 17:07                             ` Peter Zijlstra
  2018-11-29 17:31                               ` Andy Lutomirski
  2018-11-29 17:13                             ` Steven Rostedt
  2018-11-29 17:29                             ` Linus Torvalds
  2 siblings, 1 reply; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-29 17:07 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Linus Torvalds, Josh Poimboeuf, Andrew Lutomirski,
	the arch/x86 maintainers, Linux List Kernel Mailing,
	Ard Biesheuvel, Steven Rostedt, Ingo Molnar, Thomas Gleixner,
	mhiramat, jbaron, Jiri Kosina, David.Laight, bp, julia, jeyu,
	Peter Anvin

On Thu, Nov 29, 2018 at 09:02:23AM -0800, Andy Lutomirski wrote:
> > On Nov 29, 2018, at 8:50 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:

> > So no. Do *not* try to change %rsp on the stack in the bp handler.
> > Instead, I'd suggest:
> > 
> > - just restart the instruction (with the suggested "ptregs->rip --")
> > 
> > - to avoid any "oh, we're not making progress" issues, just fix the
> > instruction yourself to be the right call, by looking it up in the
> > "what needs to be fixed" tables.
> > 
> > No?

> Or do you think we can avoid the IPI while the int3 is there?

I'm thinking Linus is suggesting the #BP handler does the text write too
(as a competing store) and then sync_core() and restarts.

But I think that is broken, because then there is no telling what the
other CPUs will observe.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 16:59                           ` Andy Lutomirski
@ 2018-11-29 17:10                             ` Josh Poimboeuf
  2018-11-29 22:01                               ` Peter Zijlstra
  2018-11-29 17:15                             ` Peter Zijlstra
  1 sibling, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-29 17:10 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Peter Zijlstra, Andy Lutomirski, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> 
> 
> > On Nov 29, 2018, at 8:49 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> > 
> > On Thu, Nov 29, 2018 at 10:33:42AM -0600, Josh Poimboeuf wrote:
> >>> can't we 'fix' that again? The alternative is moving that IRET-frame and
> >>> fixing everything up, which is going to be fragile, ugly and such
> >>> things more.
> > 
> >> This seems to work...
> > 
> > That's almost too easy... nice!
> 
> It is indeed too easy: you’re putting pt_regs in the wrong place for
> int3 from user mode, which is probably a root hole if you arrange for
> a ptraced process to do int3 and try to write to whatever register
> aliases CS.
> 
> If you make it conditional on CPL, do it for 32-bit as well, add
> comments convince yourself that there isn’t a better solution

I could do that - but why subject 32-bit to it?  I was going to make it
conditional on CONFIG_HAVE_STATIC_CALL_INLINE which is 64-bit only.

> (like pointing IP at a stub that retpolines to the target by reading
> the function pointer, a la the unoptimizable version), then okay, I
> guess, with only a small amount of grumbling.

I tried that in v2, but Peter pointed out it's racy:

  https://lkml.kernel.org/r/20181126160217.GR2113@hirez.programming.kicks-ass.net

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:02                           ` Andy Lutomirski
  2018-11-29 17:07                             ` Peter Zijlstra
@ 2018-11-29 17:13                             ` Steven Rostedt
  2018-11-29 17:35                               ` Linus Torvalds
  2018-11-29 17:29                             ` Linus Torvalds
  2 siblings, 1 reply; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 17:13 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Linus Torvalds, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, 29 Nov 2018 09:02:23 -0800
Andy Lutomirski <luto@amacapital.net> wrote:


> > Instead, I'd suggest:
> > 
> > - just restart the instruction (with the suggested "ptregs->rip --")
> > 
> > - to avoid any "oh, we're not making progress" issues, just fix the
> > instruction yourself to be the right call, by looking it up in the
> > "what needs to be fixed" tables.
> > 
> > No?  
> 
> I thought that too.  I think it deadlocks. CPU A does
> text_poke_bp().  CPU B is waiting for a spinlock with IRQs off.  CPU
> C holds the spinlock and hits the int3.  The int3 never goes away
> because CPU A is waiting for CPU B to handle the sync_core IPI.

I agree that this can happen.

> 
> Or do you think we can avoid the IPI while the int3 is there?

No, we really do need to sync after we change the second part of the
command with the int3 on it. Unless there's another way to guarantee
that the full instruction gets seen when we replace the int3 with the
finished command.

To refresh everyone's memory for why we have an IPI (as IPIs have an
implicit memory barrier for the CPU).

We start with:

   e8 01 02 03 04

and we want to convert it to: e8 ab cd ef 01

And let's say the instruction crosses a cache line that breaks it into
e8 01 and 02 03 04.

We add the breakpoint:

  cc 01 02 03 04

We do a sync (so now everyone should see the break point), because we
don't want to update the second part and another CPU happens to update
the second part of the cache, and might see:

  e8 01 cd ef 01

Which would not be good.

And we need another sync after we change the code so all CPUs see

  cc ab cd ef 01

Because when we remove the break point, we don't want other CPUs to see

  e8 ab 02 03 04

Which would also be bad.

-- Steve

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 16:59                           ` Andy Lutomirski
  2018-11-29 17:10                             ` Josh Poimboeuf
@ 2018-11-29 17:15                             ` Peter Zijlstra
  2018-11-29 17:20                               ` Steven Rostedt
  2018-11-29 18:37                               ` Josh Poimboeuf
  1 sibling, 2 replies; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-29 17:15 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Josh Poimboeuf, Andy Lutomirski, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:

> If you make it conditional on CPL, do it for 32-bit as well, add
> comments, 

> and convince yourself that there isn’t a better solution
> (like pointing IP at a stub that retpolines to the target by reading
> the function pointer, a la the unoptimizable version), then okay, I
> guess, with only a small amount of grumbling.

Right; so we _could_ grow the trampoline with a retpoline indirect call
and ret. It just makes the trampoline a whole lot bigger, but it could
work.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:15                             ` Peter Zijlstra
@ 2018-11-29 17:20                               ` Steven Rostedt
  2018-11-29 17:21                                 ` Steven Rostedt
  2018-11-29 18:37                               ` Josh Poimboeuf
  1 sibling, 1 reply; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 17:20 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Andy Lutomirski, Josh Poimboeuf, Andy Lutomirski, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, 29 Nov 2018 18:15:39 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> 
> > If you make it conditional on CPL, do it for 32-bit as well, add
> > comments,   
> 
> > and convince yourself that there isn’t a better solution
> > (like pointing IP at a stub that retpolines to the target by reading
> > the function pointer, a la the unoptimizable version), then okay, I
> > guess, with only a small amount of grumbling.  
> 
> Right; so we _could_ grow the trampoline with a retpoline indirect call
> and ret. It just makes the trampoline a whole lot bigger, but it could
> work.

Can't we make use of the callee clobbered registers? I mean, we know
that call is being made when the int3 is triggered. Then we can save
the return address in one register, and the jump location in another,
and then just call a trampoline that does:

r8 = return address
r9 = function to call

	push r8
	jmp *r9

Then have the regs->ip point to that trampoline.

-- Steve

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:20                               ` Steven Rostedt
@ 2018-11-29 17:21                                 ` Steven Rostedt
  2018-11-29 17:41                                   ` Andy Lutomirski
  0 siblings, 1 reply; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 17:21 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Andy Lutomirski, Josh Poimboeuf, Andy Lutomirski, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, 29 Nov 2018 12:20:00 -0500
Steven Rostedt <rostedt@goodmis.org> wrote:


> r8 = return address
> r9 = function to call
> 

Bad example, r8 and r9 are args, but r10 and r11 are available.

-- Steve

> 	push r8
> 	jmp *r9
> 
> Then have the regs->ip point to that trampoline.
> 
> -- Steve


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:02                           ` Andy Lutomirski
  2018-11-29 17:07                             ` Peter Zijlstra
  2018-11-29 17:13                             ` Steven Rostedt
@ 2018-11-29 17:29                             ` Linus Torvalds
  2018-11-29 17:35                               ` Andy Lutomirski
  2 siblings, 1 reply; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 17:29 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Josh Poimboeuf, Peter Zijlstra, Andrew Lutomirski,
	the arch/x86 maintainers, Linux List Kernel Mailing,
	Ard Biesheuvel, Steven Rostedt, Ingo Molnar, Thomas Gleixner,
	mhiramat, jbaron, Jiri Kosina, David.Laight, bp, julia, jeyu,
	Peter Anvin

On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski <luto@amacapital.net> wrote:
> >
> > - just restart the instruction (with the suggested "ptregs->rip --")
> >
> > - to avoid any "oh, we're not making progress" issues, just fix the
> > instruction yourself to be the right call, by looking it up in the
> > "what needs to be fixed" tables.
>
> I thought that too.  I think it deadlocks. CPU A does text_poke_bp().  CPU B is waiting for a spinlock with IRQs off.  CPU C holds the spinlock and hits the int3.  The int3 never goes away because CPU A is waiting for CPU B to handle the sync_core IPI.
>
> Or do you think we can avoid the IPI while the int3 is there?

I'm handwaving and thinking that CPU C that hits the int3 can just fix
up the instruction directly in its own caches, and return.

Yes, it does what he "text_poke" *will* do (so now the instruction
gets rewritten _twice_), but who cares? It's idempotent.

And no, I don't have code, just "maybe some handwaving like this"

               Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:07                             ` Peter Zijlstra
@ 2018-11-29 17:31                               ` Andy Lutomirski
  2018-11-29 17:35                                 ` Jiri Kosina
  0 siblings, 1 reply; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29 17:31 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Linus Torvalds, Josh Poimboeuf, Andrew Lutomirski,
	the arch/x86 maintainers, Linux List Kernel Mailing,
	Ard Biesheuvel, Steven Rostedt, Ingo Molnar, Thomas Gleixner,
	mhiramat, jbaron, Jiri Kosina, David.Laight, bp, julia, jeyu,
	Peter Anvin



> On Nov 29, 2018, at 9:07 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> On Thu, Nov 29, 2018 at 09:02:23AM -0800, Andy Lutomirski wrote:
>>> On Nov 29, 2018, at 8:50 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
>>> So no. Do *not* try to change %rsp on the stack in the bp handler.
>>> Instead, I'd suggest:
>>> 
>>> - just restart the instruction (with the suggested "ptregs->rip --")
>>> 
>>> - to avoid any "oh, we're not making progress" issues, just fix the
>>> instruction yourself to be the right call, by looking it up in the
>>> "what needs to be fixed" tables.
>>> 
>>> No?
> 
>> Or do you think we can avoid the IPI while the int3 is there?
> 
> I'm thinking Linus is suggesting the #BP handler does the text write too
> (as a competing store) and then sync_core() and restarts.
> 
> But I think that is broken, because then there is no telling what the
> other CPUs will observe.

Does anyone know what the actual hardware semantics are?  The SDM is not particularly informative unless I looked at the wrong section.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:13                             ` Steven Rostedt
@ 2018-11-29 17:35                               ` Linus Torvalds
  2018-11-29 17:44                                 ` Steven Rostedt
  0 siblings, 1 reply; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 17:35 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 9:13 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> No, we really do need to sync after we change the second part of the
> command with the int3 on it. Unless there's another way to guarantee
> that the full instruction gets seen when we replace the int3 with the
> finished command.

Making sure the call instruction is aligned with the I$ fetch boundary
should do that.

It's not in the SDM, but neither was our current behavior - we
were/are just relying on "it will work".

                 Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:31                               ` Andy Lutomirski
@ 2018-11-29 17:35                                 ` Jiri Kosina
  0 siblings, 0 replies; 120+ messages in thread
From: Jiri Kosina @ 2018-11-29 17:35 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Peter Zijlstra, Linus Torvalds, Josh Poimboeuf,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Steven Rostedt,
	Ingo Molnar, Thomas Gleixner, mhiramat, jbaron, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, 29 Nov 2018, Andy Lutomirski wrote:

> Does anyone know what the actual hardware semantics are?  The SDM is not 
> particularly informative unless I looked at the wrong section.

I don't think SDM answers all the questions there, unfortunately.

I vaguely remember that back then when I was preparing the original 
text_poke_bp() implementation, hpa had to provide some answers directly 
from inner depths of Intel ... see fd4363fff3 ("x86: Introduce int3 
(breakpoint)-based instruction patching") for reference.

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:29                             ` Linus Torvalds
@ 2018-11-29 17:35                               ` Andy Lutomirski
  0 siblings, 0 replies; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29 17:35 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Josh Poimboeuf, Peter Zijlstra, Andrew Lutomirski,
	the arch/x86 maintainers, Linux List Kernel Mailing,
	Ard Biesheuvel, Steven Rostedt, Ingo Molnar, Thomas Gleixner,
	mhiramat, jbaron, Jiri Kosina, David.Laight, bp, julia, jeyu,
	Peter Anvin



> On Nov 29, 2018, at 9:29 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
> On Thu, Nov 29, 2018 at 9:02 AM Andy Lutomirski <luto@amacapital.net> wrote:
>>> 
>>> - just restart the instruction (with the suggested "ptregs->rip --")
>>> 
>>> - to avoid any "oh, we're not making progress" issues, just fix the
>>> instruction yourself to be the right call, by looking it up in the
>>> "what needs to be fixed" tables.
>> 
>> I thought that too.  I think it deadlocks. CPU A does text_poke_bp().  CPU B is waiting for a spinlock with IRQs off.  CPU C holds the spinlock and hits the int3.  The int3 never goes away because CPU A is waiting for CPU B to handle the sync_core IPI.
>> 
>> Or do you think we can avoid the IPI while the int3 is there?
> 
> I'm handwaving and thinking that CPU C that hits the int3 can just fix
> up the instruction directly in its own caches, and return.
> 
> Yes, it does what he "text_poke" *will* do (so now the instruction
> gets rewritten _twice_), but who cares? It's idempotent.
> 
> 

But it’s out of order. I’m not concerned about the final IPI — I’m concerned about the IPI after the int3 write and before the int3 is removed again. If one CPU replaces 0xcc with 0xe8, another CPU could observe that before the last couple bytes of the call target are written and observed by all CPUs.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:21                                 ` Steven Rostedt
@ 2018-11-29 17:41                                   ` Andy Lutomirski
  2018-11-29 17:45                                     ` Josh Poimboeuf
  2018-11-29 17:49                                     ` Steven Rostedt
  0 siblings, 2 replies; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29 17:41 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Peter Zijlstra, Josh Poimboeuf, Andy Lutomirski, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin


> On Nov 29, 2018, at 9:21 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> On Thu, 29 Nov 2018 12:20:00 -0500
> Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> 
>> r8 = return address
>> r9 = function to call
>> 
> 
> Bad example, r8 and r9 are args, but r10 and r11 are available.
> 
> -- Steve
> 
>>    push r8
>>    jmp *r9
>> 
>> Then have the regs->ip point to that trampoline.

Cute. That’ll need ORC annotations and some kind of retpoline to replace the indirect jump, though.

>> 
>> -- Steve
> 

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:35                               ` Linus Torvalds
@ 2018-11-29 17:44                                 ` Steven Rostedt
  2018-11-29 17:50                                   ` Linus Torvalds
  0 siblings, 1 reply; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 17:44 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, 29 Nov 2018 09:35:11 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, Nov 29, 2018 at 9:13 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > No, we really do need to sync after we change the second part of the
> > command with the int3 on it. Unless there's another way to guarantee
> > that the full instruction gets seen when we replace the int3 with the
> > finished command.  
> 
> Making sure the call instruction is aligned with the I$ fetch boundary
> should do that.
> 
> It's not in the SDM, but neither was our current behavior - we
> were/are just relying on "it will work".
>

Well, the current method (as Jiri mentioned) did get the OK from at
least Intel (and that was with a lot of arm twisting to do so).

-- Steve

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:41                                   ` Andy Lutomirski
@ 2018-11-29 17:45                                     ` Josh Poimboeuf
  2018-11-29 17:52                                       ` Andy Lutomirski
  2018-11-29 17:49                                     ` Steven Rostedt
  1 sibling, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-29 17:45 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Steven Rostedt, Peter Zijlstra, Andy Lutomirski, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 09:41:33AM -0800, Andy Lutomirski wrote:
> 
> > On Nov 29, 2018, at 9:21 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > On Thu, 29 Nov 2018 12:20:00 -0500
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > 
> >> r8 = return address
> >> r9 = function to call
> >> 
> > 
> > Bad example, r8 and r9 are args, but r10 and r11 are available.
> > 
> > -- Steve
> > 
> >>    push r8
> >>    jmp *r9
> >> 
> >> Then have the regs->ip point to that trampoline.
> 
> Cute. That’ll need ORC annotations and some kind of retpoline to replace the indirect jump, though.

I'm going with this idea, but the BP is so rare that I really don't see
why a retpoline would be needed.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:41                                   ` Andy Lutomirski
  2018-11-29 17:45                                     ` Josh Poimboeuf
@ 2018-11-29 17:49                                     ` Steven Rostedt
  1 sibling, 0 replies; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 17:49 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Peter Zijlstra, Josh Poimboeuf, Andy Lutomirski, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, 29 Nov 2018 09:41:33 -0800
Andy Lutomirski <luto@amacapital.net> wrote:

> > On Nov 29, 2018, at 9:21 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > On Thu, 29 Nov 2018 12:20:00 -0500
> > Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> >   
> >> r8 = return address
> >> r9 = function to call
> >>   
> > 
> > Bad example, r8 and r9 are args, but r10 and r11 are available.
> > 
> > -- Steve
> >   
> >>    push r8
> >>    jmp *r9
> >> 
> >> Then have the regs->ip point to that trampoline.  
> 
> Cute. That’ll need ORC annotations and some kind of retpoline to replace the indirect jump, though.
>

Do we really need to worry about retpoline here?

I'm not fully up on all the current vulnerabilities, but can this
really be taken advantage of when it only happens in the transition of
changing a static call with the small chance of one of those calls
triggering the break point?

If someone can take advantage of that, I almost think they deserve
cracking my box ;-)

-- Steve

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:44                                 ` Steven Rostedt
@ 2018-11-29 17:50                                   ` Linus Torvalds
  2018-11-29 17:54                                     ` Linus Torvalds
                                                       ` (2 more replies)
  0 siblings, 3 replies; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 17:50 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Well, the current method (as Jiri mentioned) did get the OK from at
> least Intel (and that was with a lot of arm twisting to do so).

Guys, when the comparison is to:

 - create a huge honking security hole by screwing up the stack frame

or

 - corrupt random registers because we "know" they aren't in use

then it really sounds pretty safe to just say "ok, just make it
aligned and update the instruction with an atomic cmpxchg or
something".

Of course, another option is to just say "we don't do the inline case,
then", and only ever do a call to a stub that does a "jmp"
instruction.

Problem solved, at the cost of some I$. Emulating a "jmp" is trivial,
in ways emulating a "call" is not.

              Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:45                                     ` Josh Poimboeuf
@ 2018-11-29 17:52                                       ` Andy Lutomirski
  0 siblings, 0 replies; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29 17:52 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Steven Rostedt, Peter Zijlstra, Andy Lutomirski, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin


> On Nov 29, 2018, at 9:45 AM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> 
>> On Thu, Nov 29, 2018 at 09:41:33AM -0800, Andy Lutomirski wrote:
>> 
>>> On Nov 29, 2018, at 9:21 AM, Steven Rostedt <rostedt@goodmis.org> wrote:
>>> 
>>> On Thu, 29 Nov 2018 12:20:00 -0500
>>> Steven Rostedt <rostedt@goodmis.org> wrote:
>>> 
>>> 
>>>> r8 = return address
>>>> r9 = function to call
>>>> 
>>> 
>>> Bad example, r8 and r9 are args, but r10 and r11 are available.
>>> 
>>> -- Steve
>>> 
>>>>   push r8
>>>>   jmp *r9
>>>> 
>>>> Then have the regs->ip point to that trampoline.
>> 
>> Cute. That’ll need ORC annotations and some kind of retpoline to replace the indirect jump, though.
> 
> I'm going with this idea, but the BP is so rare that I really don't see
> why a retpoline would be needed.
> 

Without the retpoline in place, you are vulnerable to security researchers causing you a personal denial of service by finding a way to cause the BP to get hit, mistraining the branch predictor, and writing a paper about it :)

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:50                                   ` Linus Torvalds
@ 2018-11-29 17:54                                     ` Linus Torvalds
  2018-11-29 17:58                                     ` Steven Rostedt
  2018-11-29 18:00                                     ` Andy Lutomirski
  2 siblings, 0 replies; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 17:54 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 9:50 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
>  - corrupt random registers because we "know" they aren't in use

Just to clarify: I think that's a completely unacceptable model.

We already have lots of special calling conventions, including ones
that do not have any call-clobbered registers at all, because we have
special magic calls in inline asm.

Some of those might be prime material for doing static calls (ie PV-op
stuff, where the native model does *not* change any registers).

So no. Don't do ugly hacks like that.

               Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:50                                   ` Linus Torvalds
  2018-11-29 17:54                                     ` Linus Torvalds
@ 2018-11-29 17:58                                     ` Steven Rostedt
  2018-11-29 18:23                                       ` Linus Torvalds
  2018-11-29 18:00                                     ` Andy Lutomirski
  2 siblings, 1 reply; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 17:58 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, 29 Nov 2018 09:50:28 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Well, the current method (as Jiri mentioned) did get the OK from at
> > least Intel (and that was with a lot of arm twisting to do so).  
> 
> Guys, when the comparison is to:
> 
>  - create a huge honking security hole by screwing up the stack frame
> 
> or
> 
>  - corrupt random registers because we "know" they aren't in use
> 
> then it really sounds pretty safe to just say "ok, just make it
> aligned and update the instruction with an atomic cmpxchg or
> something".

Do you realize that the cmpxchg used by the first attempts of the
dynamic modification of code by ftrace was the source of the e1000e
NVRAM corruption bug.

It's because it happened to do it to IO write only memory, and a
cmpxchg will *always* write, even if it didn't match. It will just
write out what it read.

In the case of the e1000e bug, it read 0xffffffff and that's what it
wrote back out.

So no, I don't think that's a better solution.

-- Steve


> 
> Of course, another option is to just say "we don't do the inline case,
> then", and only ever do a call to a stub that does a "jmp"
> instruction.
> 
> Problem solved, at the cost of some I$. Emulating a "jmp" is trivial,
> in ways emulating a "call" is not.
> 
>               Linus


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:50                                   ` Linus Torvalds
  2018-11-29 17:54                                     ` Linus Torvalds
  2018-11-29 17:58                                     ` Steven Rostedt
@ 2018-11-29 18:00                                     ` Andy Lutomirski
  2018-11-29 18:42                                       ` Linus Torvalds
  2018-11-29 18:55                                       ` Steven Rostedt
  2 siblings, 2 replies; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29 18:00 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin


> On Nov 29, 2018, at 9:50 AM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
>> On Thu, Nov 29, 2018 at 9:44 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>> 
>> Well, the current method (as Jiri mentioned) did get the OK from at
>> least Intel (and that was with a lot of arm twisting to do so).
> 
> Guys, when the comparison is to:
> 
> - create a huge honking security hole by screwing up the stack frame
> 
> or
> 
> - corrupt random registers because we "know" they aren't in use

For C calls, we do indeed know that.  But I guess there could be asm calls.

> 
> then it really sounds pretty safe to just say "ok, just make it
> aligned and update the instruction with an atomic cmpxchg or
> something".

And how do we do that?  With a gcc plugin and some asm magic?

> 
> Of course, another option is to just say "we don't do the inline case,
> then", and only ever do a call to a stub that does a "jmp"
> instruction.

That’s not a terrible idea.

> 
> Problem solved, at the cost of some I$. Emulating a "jmp" is trivial,
> in ways emulating a "call" is not.
> 
> 



^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:58                                     ` Steven Rostedt
@ 2018-11-29 18:23                                       ` Linus Torvalds
  2018-11-29 18:47                                         ` Steven Rostedt
  0 siblings, 1 reply; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 18:23 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 9:59 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Do you realize that the cmpxchg used by the first attempts of the
> dynamic modification of code by ftrace was the source of the e1000e
> NVRAM corruption bug.

If you have a static call in IO memory, you have bigger problems than that.

What's your point?

Again - I will point out that the things you guys have tried to come
up with have been *WORSE*. Much worse.

               Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:15                             ` Peter Zijlstra
  2018-11-29 17:20                               ` Steven Rostedt
@ 2018-11-29 18:37                               ` Josh Poimboeuf
  1 sibling, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-29 18:37 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Andy Lutomirski, Andy Lutomirski, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 06:15:39PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> 
> > If you make it conditional on CPL, do it for 32-bit as well, add
> > comments, 
> 
> > and convince yourself that there isn’t a better solution
> > (like pointing IP at a stub that retpolines to the target by reading
> > the function pointer, a la the unoptimizable version), then okay, I
> > guess, with only a small amount of grumbling.
> 
> Right; so we _could_ grow the trampoline with a retpoline indirect call
> and ret. It just makes the trampoline a whole lot bigger, but it could
> work.

I'm trying to envision how this would work.  How would the function (or
stub) know how to return back to the call site?

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 18:00                                     ` Andy Lutomirski
@ 2018-11-29 18:42                                       ` Linus Torvalds
  2018-11-29 18:55                                       ` Steven Rostedt
  1 sibling, 0 replies; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 18:42 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Steven Rostedt, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 10:00 AM Andy Lutomirski <luto@amacapital.net> wrote:
> > then it really sounds pretty safe to just say "ok, just make it
> > aligned and update the instruction with an atomic cmpxchg or
> > something".
>
> And how do we do that?  With a gcc plugin and some asm magic?

Asm magic.

You already have to mark the call sites with

    static_call(fn, arg1, arg2, ...);

and while it right now just magically depends on gcc outputting the
right code to call the trampoline. But it could do it as a jmp
instruction (tail-call), and maybe that works right, maybe it doesn't.
And maybe some gcc switch makes it output it as a indirect call due to
instrumentation or something. Doing it with asm magic would, I feel,
be safer anyway, so that we'd know *exactly* how that call gets done.

For example, if gcc does it as a jmp due to a tail-call, the
compiler/linker could in theory turn the jump into a short jump if it
sees that the trampoline is close enough. Does that happen? Probably
not. But I don't see why it *couldn't* happen in the current patch
series. The trampoline is just a regular function, even if it has been
defined by global asm.

Putting the trampoline in a different code section could fix things
like that (maybe there was a patch that did that and I missed it?) but
I do think that doing the call with an asm would *also* fix it.

But the "just always use a trampoline" is certainly the simpler model.

                  Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 18:23                                       ` Linus Torvalds
@ 2018-11-29 18:47                                         ` Steven Rostedt
  2018-11-29 18:58                                           ` Linus Torvalds
  0 siblings, 1 reply; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 18:47 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, 29 Nov 2018 10:23:44 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, Nov 29, 2018 at 9:59 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Do you realize that the cmpxchg used by the first attempts of the
> > dynamic modification of code by ftrace was the source of the e1000e
> > NVRAM corruption bug.  
> 
> If you have a static call in IO memory, you have bigger problems than that.
> 
> What's your point?

Just that cmpxchg on dynamic modified code brings back bad memories ;-)

> 
> Again - I will point out that the things you guys have tried to come
> up with have been *WORSE*. Much worse.

Note, we do have a bit of control at what is getting called. The patch
set requires that the callers are wrapped in macros. We should not
allow just any random callers (like from asm).

This isn't about modifying any function call. This is for a specific
subset, that we can impose rules on.

-- Steve


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 18:00                                     ` Andy Lutomirski
  2018-11-29 18:42                                       ` Linus Torvalds
@ 2018-11-29 18:55                                       ` Steven Rostedt
  1 sibling, 0 replies; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 18:55 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Linus Torvalds, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, 29 Nov 2018 10:00:48 -0800
Andy Lutomirski <luto@amacapital.net> wrote:

> > 
> > Of course, another option is to just say "we don't do the inline case,
> > then", and only ever do a call to a stub that does a "jmp"
> > instruction.  
> 
> That’s not a terrible idea.

It was the implementation of my first proof of concept that kicked off
this entire idea, where others (Peter and Josh) thought it was better
to modify the calls themselves. It does improve things.

Just a reminder of the benchmarks of enabling all tracepoints (which
use indirect jumps) and running hackbench:

  No RETPOLINES:
            1.4503 +- 0.0148 seconds time elapsed  ( +-  1.02% )

  baseline RETPOLINES:
            1.5120 +- 0.0133 seconds time elapsed  ( +-  0.88% )

  Added direct calls for trace_events:
            1.5239 +- 0.0139 seconds time elapsed  ( +-  0.91% )

  With static calls:
            1.5282 +- 0.0135 seconds time elapsed  ( +-  0.88% )

  With static call trampolines:
           1.48328 +- 0.00515 seconds time elapsed  ( +-  0.35% )

  Full static calls:
           1.47364 +- 0.00706 seconds time elapsed  ( +-  0.48% )


  Adding Retpolines caused a 1.5120 / 1.4503 = 1.0425 ( 4.25% ) slowdown

  Trampolines made it into 1.48328 / 1.4503 = 1.0227 ( 2.27% ) slowdown

The above is the stub with the jmp case.

  With full static calls 1.47364 / 1.4503 = 1.0160 ( 1.6% ) slowdown

Modifying the calls themselves does have an improvement (and this is
much greater of an improvement when I had debugging enabled).

Perhaps it's not worth the effort, but again, we do have control of
what uses this. It's not a total free-for-all.

Full results here:

  http://lkml.kernel.org/r/20181126155405.72b4f718@gandalf.local.home

Although since lore.kernel.org seems to be having issues:

  https://marc.info/?l=linux-kernel&m=154326714710686


-- Steve

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 18:47                                         ` Steven Rostedt
@ 2018-11-29 18:58                                           ` Linus Torvalds
  2018-11-29 19:08                                             ` Linus Torvalds
                                                               ` (2 more replies)
  0 siblings, 3 replies; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 18:58 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> Note, we do have a bit of control at what is getting called. The patch
> set requires that the callers are wrapped in macros. We should not
> allow just any random callers (like from asm).

Actually, I'd argue that asm is often more controlled than C code.

Right now you can do odd things if you really want to, and have the
compiler generate indirect calls to those wrapper functions.

For example, I can easily imagine a pre-retpoline compiler turning

     if (cond)
        fn1(a,b)
     else
       fn2(a,b);

into a function pointer conditional

    (cond ? fn1 : fn2)(a,b);

and honestly, the way "static_call()" works now, can you guarantee
that the call-site doesn't end up doing that, and calling the
trampoline function for two different static calls from one indirect
call?

See what I'm talking about? Saying "callers are wrapped in macros"
doesn't actually protect you from the compiler doing things like that.

In contrast, if the call was wrapped in an inline asm, we'd *know* the
compiler couldn't turn a "call wrapper(%rip)" into anything else.

                  Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 18:58                                           ` Linus Torvalds
@ 2018-11-29 19:08                                             ` Linus Torvalds
  2018-11-29 19:11                                               ` Linus Torvalds
                                                                 ` (2 more replies)
  2018-11-29 19:16                                             ` Steven Rostedt
  2018-11-29 20:12                                             ` Josh Poimboeuf
  2 siblings, 3 replies; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 19:08 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> In contrast, if the call was wrapped in an inline asm, we'd *know* the
> compiler couldn't turn a "call wrapper(%rip)" into anything else.

Actually, I think I have a better model - if the caller is done with inline asm.

What you can do then is basically add a single-byte prefix to the
"call" instruction that does nothing (say, cs override), and then
replace *that* with a 'int3' instruction.

Boom. Done.

Now, the "int3" handler can just update the instruction in-place, but
leave the "int3" in place, and then return to the next instruction
byte (which is just the normal branch instruction without the prefix
byte).

The cross-CPU case continues to work, because the 'int3' remains in
place until after the IPI.

But that would require that we'd mark those call instruction with

                  Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 19:08                                             ` Linus Torvalds
@ 2018-11-29 19:11                                               ` Linus Torvalds
  2018-12-10 23:58                                                 ` Pavel Machek
  2018-11-29 19:12                                               ` Steven Rostedt
  2018-11-29 19:27                                               ` Andy Lutomirski
  2 siblings, 1 reply; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 19:11 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> What you can do then is basically add a single-byte prefix to the
> "call" instruction that does nothing (say, cs override), and then
> replace *that* with a 'int3' instruction.

Hmm. the segment prefixes are documented as being "reserved" for
branch instructions. I *think* that means just conditional branches
(Intel at one point used the prefixes for static prediction
information), not "call", but who knows..

It might be better to use an empty REX prefix on x86-64 or something like that.

               Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 19:08                                             ` Linus Torvalds
  2018-11-29 19:11                                               ` Linus Torvalds
@ 2018-11-29 19:12                                               ` Steven Rostedt
  2018-11-29 19:27                                               ` Andy Lutomirski
  2 siblings, 0 replies; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 19:12 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, 29 Nov 2018 11:08:26 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > compiler couldn't turn a "call wrapper(%rip)" into anything else.  
> 
> Actually, I think I have a better model - if the caller is done with inline asm.
> 
> What you can do then is basically add a single-byte prefix to the
> "call" instruction that does nothing (say, cs override), and then
> replace *that* with a 'int3' instruction.
> 
> Boom. Done.
> 
> Now, the "int3" handler can just update the instruction in-place, but
> leave the "int3" in place, and then return to the next instruction
> byte (which is just the normal branch instruction without the prefix
> byte).
> 
> The cross-CPU case continues to work, because the 'int3' remains in
> place until after the IPI.
> 
> But that would require that we'd mark those call instruction with
> 

In my original proof of concept, I tried to to implement the callers
with asm, but then the way to handle parameters became a nightmare.

The goal of this (for me) was to replace the tracepoint indirect calls
with static calls, and tracepoints can have any number of parameters to
pass. I ended up needing the compiler to help me with the passing of
parameters.

-- Steve

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 18:58                                           ` Linus Torvalds
  2018-11-29 19:08                                             ` Linus Torvalds
@ 2018-11-29 19:16                                             ` Steven Rostedt
  2018-11-29 19:22                                               ` Josh Poimboeuf
  2018-11-29 19:24                                               ` Linus Torvalds
  2018-11-29 20:12                                             ` Josh Poimboeuf
  2 siblings, 2 replies; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 19:16 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, 29 Nov 2018 10:58:40 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Note, we do have a bit of control at what is getting called. The patch
> > set requires that the callers are wrapped in macros. We should not
> > allow just any random callers (like from asm).  
> 
> Actually, I'd argue that asm is often more controlled than C code.
> 
> Right now you can do odd things if you really want to, and have the
> compiler generate indirect calls to those wrapper functions.
> 
> For example, I can easily imagine a pre-retpoline compiler turning
> 
>      if (cond)
>         fn1(a,b)
>      else
>        fn2(a,b);
> 
> into a function pointer conditional
> 
>     (cond ? fn1 : fn2)(a,b);

If we are worried about such a construct, wouldn't a compiler barrier
before and after the static_call solve that?

	barrier();
	static_call(func...);
	barrier();

It should also stop tail calls too.

> 
> and honestly, the way "static_call()" works now, can you guarantee
> that the call-site doesn't end up doing that, and calling the
> trampoline function for two different static calls from one indirect
> call?
> 
> See what I'm talking about? Saying "callers are wrapped in macros"
> doesn't actually protect you from the compiler doing things like that.
> 
> In contrast, if the call was wrapped in an inline asm, we'd *know* the
> compiler couldn't turn a "call wrapper(%rip)" into anything else.

But then we need to implement all numbers of parameters.

-- Steve

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 19:16                                             ` Steven Rostedt
@ 2018-11-29 19:22                                               ` Josh Poimboeuf
  2018-11-29 19:27                                                 ` Steven Rostedt
  2018-11-30 22:16                                                 ` Rasmus Villemoes
  2018-11-29 19:24                                               ` Linus Torvalds
  1 sibling, 2 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-29 19:22 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Linus Torvalds, Andy Lutomirski, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
> > and honestly, the way "static_call()" works now, can you guarantee
> > that the call-site doesn't end up doing that, and calling the
> > trampoline function for two different static calls from one indirect
> > call?
> > 
> > See what I'm talking about? Saying "callers are wrapped in macros"
> > doesn't actually protect you from the compiler doing things like that.
> > 
> > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > compiler couldn't turn a "call wrapper(%rip)" into anything else.
> 
> But then we need to implement all numbers of parameters.

I actually have an old unfinished patch which (ab)used C macros to
detect the number of parameters and then setup the asm constraints
accordingly.  At the time, the goal was to optimize the BUG code.

I had wanted to avoid this kind of approach for static calls, because
"ugh", but now it's starting to look much more appealing.

Behold:

diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
index aa6b2023d8f8..d63e9240da77 100644
--- a/arch/x86/include/asm/bug.h
+++ b/arch/x86/include/asm/bug.h
@@ -32,10 +32,59 @@
 
 #ifdef CONFIG_DEBUG_BUGVERBOSE
 
-#define _BUG_FLAGS(ins, flags)						\
+#define __BUG_ARGS_0(ins, ...) \
+({\
+	asm volatile("1:\t" ins "\n"); \
+})
+#define __BUG_ARGS_1(ins, ...) \
+({\
+	asm volatile("1:\t" ins "\n" \
+		     : : "D" (ARG1(__VA_ARGS__))); \
+})
+#define __BUG_ARGS_2(ins, ...) \
+({\
+	asm volatile("1:\t" ins "\n" \
+		     : : "D" (ARG1(__VA_ARGS__)), \
+			 "S" (ARG2(__VA_ARGS__))); \
+})
+#define __BUG_ARGS_3(ins, ...) \
+({\
+	asm volatile("1:\t" ins "\n" \
+		     : : "D" (ARG1(__VA_ARGS__)), \
+			 "S" (ARG2(__VA_ARGS__)), \
+			 "d" (ARG3(__VA_ARGS__))); \
+})
+#define __BUG_ARGS_4(ins, ...) \
+({\
+	asm volatile("1:\t" ins "\n" \
+		     : : "D" (ARG1(__VA_ARGS__)), \
+			 "S" (ARG2(__VA_ARGS__)), \
+			 "d" (ARG3(__VA_ARGS__)), \
+			 "c" (ARG4(__VA_ARGS__))); \
+})
+#define __BUG_ARGS_5(ins, ...) \
+({\
+	register u64 __r8 asm("r8") = (u64)ARG5(__VA_ARGS__); \
+	asm volatile("1:\t" ins "\n" \
+		     : : "D" (ARG1(__VA_ARGS__)), \
+			 "S" (ARG2(__VA_ARGS__)), \
+			 "d" (ARG3(__VA_ARGS__)), \
+			 "c" (ARG4(__VA_ARGS__)), \
+			 "r" (__r8)); \
+})
+#define __BUG_ARGS_6 foo
+#define __BUG_ARGS_7 foo
+#define __BUG_ARGS_8 foo
+#define __BUG_ARGS_9 foo
+
+#define __BUG_ARGS(ins, num, ...) __BUG_ARGS_ ## num(ins, __VA_ARGS__)
+
+#define _BUG_ARGS(ins, num, ...) __BUG_ARGS(ins, num, __VA_ARGS__)
+
+#define _BUG_FLAGS(ins, flags, ...)					\
 do {									\
-	asm volatile("1:\t" ins "\n"					\
-		     ".pushsection __bug_table,\"aw\"\n"		\
+	_BUG_ARGS(ins, NUM_ARGS(__VA_ARGS__), __VA_ARGS__);	\
+	asm volatile(".pushsection __bug_table,\"aw\"\n"		\
 		     "2:\t" __BUG_REL(1b) "\t# bug_entry::bug_addr\n"	\
 		     "\t"  __BUG_REL(%c0) "\t# bug_entry::file\n"	\
 		     "\t.word %c1"        "\t# bug_entry::line\n"	\
@@ -76,7 +125,7 @@ do {								\
 	unreachable();						\
 } while (0)
 
-#define __WARN_FLAGS(flags)	_BUG_FLAGS(ASM_UD0, BUGFLAG_WARNING|(flags))
+#define __WARN_FLAGS(flags, ...)	_BUG_FLAGS(ASM_UD0, BUGFLAG_WARNING|(flags), __VA_ARGS__)
 
 #include <asm-generic/bug.h>
 
diff --git a/include/asm-generic/bug.h b/include/asm-generic/bug.h
index 70c7732c9594..0cb16e912c02 100644
--- a/include/asm-generic/bug.h
+++ b/include/asm-generic/bug.h
@@ -58,8 +58,8 @@ struct bug_entry {
 #endif
 
 #ifdef __WARN_FLAGS
-#define __WARN_TAINT(taint)		__WARN_FLAGS(BUGFLAG_TAINT(taint))
-#define __WARN_ONCE_TAINT(taint)	__WARN_FLAGS(BUGFLAG_ONCE|BUGFLAG_TAINT(taint))
+#define __WARN_TAINT(taint, args...)		__WARN_FLAGS(BUGFLAG_TAINT(taint), args)
+#define __WARN_ONCE_TAINT(taint, args...)	__WARN_FLAGS(BUGFLAG_ONCE|BUGFLAG_TAINT(taint), args)
 
 #define WARN_ON_ONCE(condition) ({				\
 	int __ret_warn_on = !!(condition);			\
@@ -84,11 +84,12 @@ void warn_slowpath_fmt_taint(const char *file, const int line, unsigned taint,
 extern void warn_slowpath_null(const char *file, const int line);
 #ifdef __WARN_TAINT
 #define __WARN()		__WARN_TAINT(TAINT_WARN)
+#define __WARN_printf(args...)	__WARN_TAINT(TAINT_WARN, args)
 #else
 #define __WARN()		warn_slowpath_null(__FILE__, __LINE__)
+#define __WARN_printf(arg...)	warn_slowpath_fmt(__FILE__, __LINE__, arg)
 #endif
 
-#define __WARN_printf(arg...)	warn_slowpath_fmt(__FILE__, __LINE__, arg)
 #define __WARN_printf_taint(taint, arg...)				\
 	warn_slowpath_fmt_taint(__FILE__, __LINE__, taint, arg)
 /* used internally by panic.c */
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 2d2721756abf..e641552e17cf 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -192,6 +192,14 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
 # define unreachable() do { } while (1)
 #endif
 
+#define __NUM_ARGS(_0, _1, _2, _3, _4, _5, _6, _7, _8, _9, _10, N, ...) N
+#define NUM_ARGS(...) __NUM_ARGS(0, ## __VA_ARGS__, 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, 0)
+#define ARG1(_1, ...) _1
+#define ARG2(_1, _2, ...) _2
+#define ARG3(_1, _2, _3, ...) _3
+#define ARG4(_1, _2, _3, _4, ...) _4
+#define ARG5(_1, _2, _3, _4, _5, ...) _5
+
 /*
  * KENTRY - kernel entry point
  * This can be used to annotate symbols (functions or data) that are used

-- 
Josh

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 19:16                                             ` Steven Rostedt
  2018-11-29 19:22                                               ` Josh Poimboeuf
@ 2018-11-29 19:24                                               ` Linus Torvalds
  2018-11-29 19:28                                                 ` Andy Lutomirski
  2018-11-29 19:31                                                 ` Steven Rostedt
  1 sibling, 2 replies; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 19:24 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> But then we need to implement all numbers of parameters.

Oh, I agree, it's nasty.

But it's actually a nastiness that we've solved before. In particular,
with the system call mappings, which have pretty much the exact same
issue of "map unknown number of arguments to registers".

Yes, it's different - there you map the unknown number of arguments to
a structure access instead. And yes, the macros are unbelievably ugly.
See

    arch/x86/include/asm/syscall_wrapper.h

and the __MAP() macro from

    include/linux/syscalls.h

so it's not pretty. But it would solve all the problems.

              Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 19:08                                             ` Linus Torvalds
  2018-11-29 19:11                                               ` Linus Torvalds
  2018-11-29 19:12                                               ` Steven Rostedt
@ 2018-11-29 19:27                                               ` Andy Lutomirski
  2018-11-29 20:24                                                 ` Josh Poimboeuf
  2 siblings, 1 reply; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29 19:27 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, X86 ML, LKML, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, Masami Hiramatsu, Jason Baron, Jiri Kosina,
	David Laight, Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > compiler couldn't turn a "call wrapper(%rip)" into anything else.
>
> Actually, I think I have a better model - if the caller is done with inline asm.
>
> What you can do then is basically add a single-byte prefix to the
> "call" instruction that does nothing (say, cs override), and then
> replace *that* with a 'int3' instruction.
>
> Boom. Done.
>
> Now, the "int3" handler can just update the instruction in-place, but
> leave the "int3" in place, and then return to the next instruction
> byte (which is just the normal branch instruction without the prefix
> byte).
>
> The cross-CPU case continues to work, because the 'int3' remains in
> place until after the IPI.

Hmm, cute.  But then the calls are in inline asm, which results in
giant turds like we have for the pvop vcalls.  And, if they start
being used more generally, we potentially have ABI issues where the
calling convention isn't quite what the asm expects, and we explode.

I propose a different solution:

As in this patch set, we have a direct and an indirect version.  The
indirect version remains exactly the same as in this patch set.  The
direct version just only does the patching when all seems well: the
call instruction needs to be 0xe8, and we only do it when the thing
doesn't cross a cache line.  Does that work?  In the rare case where
the compiler generates something other than 0xe8 or crosses a cache
line, then the thing just remains as a call to the out of line jmp
trampoline.  Does that seem reasonable?  It's a very minor change to
the patch set.

Alternatively, we could actually emulate call instructions like this:

void __noreturn jump_to_kernel_pt_regs(struct pt_regs *regs, ...)
{
  struct pt_regs ptregs_copy = *regs;
  barrier();
  *(unsigned long *)(regs->sp - 8) = whatever;  /* may clobber old
regs, but so what? */
  asm volatile ("jmp return_to_alternate_ptregs");
}

where return_to_alternate_ptregs points rsp to the ptregs and goes
through the normal return path.  It's ugly, but we could have a test
case for it, and it should work fine.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 19:22                                               ` Josh Poimboeuf
@ 2018-11-29 19:27                                                 ` Steven Rostedt
  2018-11-30 22:16                                                 ` Rasmus Villemoes
  1 sibling, 0 replies; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 19:27 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Linus Torvalds, Andy Lutomirski, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, 29 Nov 2018 13:22:11 -0600
Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
> > > and honestly, the way "static_call()" works now, can you guarantee
> > > that the call-site doesn't end up doing that, and calling the
> > > trampoline function for two different static calls from one indirect
> > > call?
> > > 
> > > See what I'm talking about? Saying "callers are wrapped in macros"
> > > doesn't actually protect you from the compiler doing things like that.
> > > 
> > > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > > compiler couldn't turn a "call wrapper(%rip)" into anything else.  
> > 
> > But then we need to implement all numbers of parameters.  
> 
> I actually have an old unfinished patch which (ab)used C macros to
> detect the number of parameters and then setup the asm constraints
> accordingly.  At the time, the goal was to optimize the BUG code.
> 
> I had wanted to avoid this kind of approach for static calls, because
> "ugh", but now it's starting to look much more appealing.
> 
> Behold:
> 
> diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
> index aa6b2023d8f8..d63e9240da77 100644
> --- a/arch/x86/include/asm/bug.h
> +++ b/arch/x86/include/asm/bug.h
> @@ -32,10 +32,59 @@
>  
>  #ifdef CONFIG_DEBUG_BUGVERBOSE
>  
> -#define _BUG_FLAGS(ins, flags)						\
> +#define __BUG_ARGS_0(ins, ...) \
> +({\
> +	asm volatile("1:\t" ins "\n"); \
> +})
> +#define __BUG_ARGS_1(ins, ...) \
> +({\
> +	asm volatile("1:\t" ins "\n" \
> +		     : : "D" (ARG1(__VA_ARGS__))); \
> +})
> +#define __BUG_ARGS_2(ins, ...) \
> +({\
> +	asm volatile("1:\t" ins "\n" \
> +		     : : "D" (ARG1(__VA_ARGS__)), \
> +			 "S" (ARG2(__VA_ARGS__))); \
> +})
> +#define __BUG_ARGS_3(ins, ...) \
> +({\
> +	asm volatile("1:\t" ins "\n" \
> +		     : : "D" (ARG1(__VA_ARGS__)), \
> +			 "S" (ARG2(__VA_ARGS__)), \
> +			 "d" (ARG3(__VA_ARGS__))); \
> +})
> +#define __BUG_ARGS_4(ins, ...) \
> +({\
> +	asm volatile("1:\t" ins "\n" \
> +		     : : "D" (ARG1(__VA_ARGS__)), \
> +			 "S" (ARG2(__VA_ARGS__)), \
> +			 "d" (ARG3(__VA_ARGS__)), \
> +			 "c" (ARG4(__VA_ARGS__))); \
> +})
> +#define __BUG_ARGS_5(ins, ...) \
> +({\
> +	register u64 __r8 asm("r8") = (u64)ARG5(__VA_ARGS__); \
> +	asm volatile("1:\t" ins "\n" \
> +		     : : "D" (ARG1(__VA_ARGS__)), \
> +			 "S" (ARG2(__VA_ARGS__)), \
> +			 "d" (ARG3(__VA_ARGS__)), \
> +			 "c" (ARG4(__VA_ARGS__)), \
> +			 "r" (__r8)); \
> +})
> +#define __BUG_ARGS_6 foo
> +#define __BUG_ARGS_7 foo
> +#define __BUG_ARGS_8 foo
> +#define __BUG_ARGS_9 foo
> +


There exist tracepoints with 13 arguments.

-- Steve

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 19:24                                               ` Linus Torvalds
@ 2018-11-29 19:28                                                 ` Andy Lutomirski
  2018-11-29 19:31                                                 ` Steven Rostedt
  1 sibling, 0 replies; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29 19:28 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, X86 ML, LKML, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, Masami Hiramatsu, Jason Baron, Jiri Kosina,
	David Laight, Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 11:25 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > But then we need to implement all numbers of parameters.
>
> Oh, I agree, it's nasty.
>
> But it's actually a nastiness that we've solved before. In particular,
> with the system call mappings, which have pretty much the exact same
> issue of "map unknown number of arguments to registers".
>
> Yes, it's different - there you map the unknown number of arguments to
> a structure access instead. And yes, the macros are unbelievably ugly.
> See
>
>     arch/x86/include/asm/syscall_wrapper.h
>
> and the __MAP() macro from
>
>     include/linux/syscalls.h
>
> so it's not pretty. But it would solve all the problems.
>

Until someone does:

struct foo foo;
static_call(thingy, foo);

For syscalls, we know better than to do that.  For static calls, I'm
less confident.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 19:24                                               ` Linus Torvalds
  2018-11-29 19:28                                                 ` Andy Lutomirski
@ 2018-11-29 19:31                                                 ` Steven Rostedt
  1 sibling, 0 replies; 120+ messages in thread
From: Steven Rostedt @ 2018-11-29 19:31 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, 29 Nov 2018 11:24:43 -0800
Linus Torvalds <torvalds@linux-foundation.org> wrote:

> On Thu, Nov 29, 2018 at 11:16 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > But then we need to implement all numbers of parameters.  
> 
> Oh, I agree, it's nasty.
> 
> But it's actually a nastiness that we've solved before. In particular,
> with the system call mappings, which have pretty much the exact same
> issue of "map unknown number of arguments to registers".
> 
> Yes, it's different - there you map the unknown number of arguments to
> a structure access instead. And yes, the macros are unbelievably ugly.
> See
> 
>     arch/x86/include/asm/syscall_wrapper.h

Those are not doing inline assembly.

> 
> and the __MAP() macro from
> 
>     include/linux/syscalls.h
> 
> so it's not pretty. But it would solve all the problems.
> 

Again, not inline assembly, and those only handle up to 6 parameters.

My POC started down this route, until I notice that there's tracepoints
that have 13 parameters! And I need to handle all tracepoints.

Yes, we can argue that we need to change those (if that doesn't break
the API of something using it).

-- Steve


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 18:58                                           ` Linus Torvalds
  2018-11-29 19:08                                             ` Linus Torvalds
  2018-11-29 19:16                                             ` Steven Rostedt
@ 2018-11-29 20:12                                             ` Josh Poimboeuf
  2 siblings, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-29 20:12 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, Andy Lutomirski, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 10:58:40AM -0800, Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 10:47 AM Steven Rostedt <rostedt@goodmis.org> wrote:
> >
> > Note, we do have a bit of control at what is getting called. The patch
> > set requires that the callers are wrapped in macros. We should not
> > allow just any random callers (like from asm).
> 
> Actually, I'd argue that asm is often more controlled than C code.
> 
> Right now you can do odd things if you really want to, and have the
> compiler generate indirect calls to those wrapper functions.
> 
> For example, I can easily imagine a pre-retpoline compiler turning
> 
>      if (cond)
>         fn1(a,b)
>      else
>        fn2(a,b);
> 
> into a function pointer conditional
> 
>     (cond ? fn1 : fn2)(a,b);
> 
> and honestly, the way "static_call()" works now, can you guarantee
> that the call-site doesn't end up doing that, and calling the
> trampoline function for two different static calls from one indirect
> call?
> 
> See what I'm talking about? Saying "callers are wrapped in macros"
> doesn't actually protect you from the compiler doing things like that.
> 
> In contrast, if the call was wrapped in an inline asm, we'd *know* the
> compiler couldn't turn a "call wrapper(%rip)" into anything else.

I think objtool could warn about many such issues, including function
pointer references to trampolines and short tail call jumps.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 19:27                                               ` Andy Lutomirski
@ 2018-11-29 20:24                                                 ` Josh Poimboeuf
  2018-11-29 22:17                                                   ` Josh Poimboeuf
                                                                     ` (2 more replies)
  0 siblings, 3 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-29 20:24 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Linus Torvalds, Steven Rostedt, Peter Zijlstra, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > > compiler couldn't turn a "call wrapper(%rip)" into anything else.
> >
> > Actually, I think I have a better model - if the caller is done with inline asm.
> >
> > What you can do then is basically add a single-byte prefix to the
> > "call" instruction that does nothing (say, cs override), and then
> > replace *that* with a 'int3' instruction.
> >
> > Boom. Done.
> >
> > Now, the "int3" handler can just update the instruction in-place, but
> > leave the "int3" in place, and then return to the next instruction
> > byte (which is just the normal branch instruction without the prefix
> > byte).
> >
> > The cross-CPU case continues to work, because the 'int3' remains in
> > place until after the IPI.
> 
> Hmm, cute.  But then the calls are in inline asm, which results in
> giant turds like we have for the pvop vcalls.  And, if they start
> being used more generally, we potentially have ABI issues where the
> calling convention isn't quite what the asm expects, and we explode.
> 
> I propose a different solution:
> 
> As in this patch set, we have a direct and an indirect version.  The
> indirect version remains exactly the same as in this patch set.  The
> direct version just only does the patching when all seems well: the
> call instruction needs to be 0xe8, and we only do it when the thing
> doesn't cross a cache line.  Does that work?  In the rare case where
> the compiler generates something other than 0xe8 or crosses a cache
> line, then the thing just remains as a call to the out of line jmp
> trampoline.  Does that seem reasonable?  It's a very minor change to
> the patch set.

Maybe that would be ok.  If my math is right, we would use the
out-of-line version almost 5% of the time due to cache misalignment of
the address.

> Alternatively, we could actually emulate call instructions like this:
> 
> void __noreturn jump_to_kernel_pt_regs(struct pt_regs *regs, ...)
> {
>   struct pt_regs ptregs_copy = *regs;
>   barrier();
>   *(unsigned long *)(regs->sp - 8) = whatever;  /* may clobber old
> regs, but so what? */
>   asm volatile ("jmp return_to_alternate_ptregs");
> }
> 
> where return_to_alternate_ptregs points rsp to the ptregs and goes
> through the normal return path.  It's ugly, but we could have a test
> case for it, and it should work fine.

Is that really any better than my patch to create a gap in the stack
(modified for kernel space #BP only)?

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 17:10                             ` Josh Poimboeuf
@ 2018-11-29 22:01                               ` Peter Zijlstra
  2018-11-29 22:14                                 ` Josh Poimboeuf
  0 siblings, 1 reply; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-29 22:01 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Andy Lutomirski, Andy Lutomirski, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:

> > (like pointing IP at a stub that retpolines to the target by reading
> > the function pointer, a la the unoptimizable version), then okay, I
> > guess, with only a small amount of grumbling.
> 
> I tried that in v2, but Peter pointed out it's racy:
> 
>   https://lkml.kernel.org/r/20181126160217.GR2113@hirez.programming.kicks-ass.net

Ah, but that is because it is a global shared trampoline.

Each static_call has it's own trampoline; which currently reads
something like:

	RETPOLINE_SAFE
	JMP *key

which you then 'defuse' by writing an UD2 on. _However_, if you write
that trampoline like:

1:	RETPOLINE_SAFE
	JMP *key
2:	CALL_NOSPEC *key
	RET

and have the text_poke_bp() handler jump to 2 (a location you'll never
reach when you enter at 1), it will in fact work I think. The trampoline
is never modified and not shared between different static_call's.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 22:01                               ` Peter Zijlstra
@ 2018-11-29 22:14                                 ` Josh Poimboeuf
  2018-11-29 22:22                                   ` Peter Zijlstra
  0 siblings, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-29 22:14 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Andy Lutomirski, Andy Lutomirski, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> 
> > > (like pointing IP at a stub that retpolines to the target by reading
> > > the function pointer, a la the unoptimizable version), then okay, I
> > > guess, with only a small amount of grumbling.
> > 
> > I tried that in v2, but Peter pointed out it's racy:
> > 
> >   https://lkml.kernel.org/r/20181126160217.GR2113@hirez.programming.kicks-ass.net
> 
> Ah, but that is because it is a global shared trampoline.
> 
> Each static_call has it's own trampoline; which currently reads
> something like:
> 
> 	RETPOLINE_SAFE
> 	JMP *key
> 
> which you then 'defuse' by writing an UD2 on. _However_, if you write
> that trampoline like:
> 
> 1:	RETPOLINE_SAFE
> 	JMP *key
> 2:	CALL_NOSPEC *key
> 	RET
> 
> and have the text_poke_bp() handler jump to 2 (a location you'll never
> reach when you enter at 1), it will in fact work I think. The trampoline
> is never modified and not shared between different static_call's.

But after returning from the function to the trampoline, how does it
return from the trampoline to the call site?  At that point there is no
return address on the stack.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 20:24                                                 ` Josh Poimboeuf
@ 2018-11-29 22:17                                                   ` Josh Poimboeuf
  2018-11-29 23:04                                                   ` Linus Torvalds
  2018-11-30 16:42                                                   ` Andy Lutomirski
  2 siblings, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-29 22:17 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Linus Torvalds, Steven Rostedt, Peter Zijlstra, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 02:24:52PM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> > On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
> > <torvalds@linux-foundation.org> wrote:
> > >
> > > On Thu, Nov 29, 2018 at 10:58 AM Linus Torvalds
> > > <torvalds@linux-foundation.org> wrote:
> > > >
> > > > In contrast, if the call was wrapped in an inline asm, we'd *know* the
> > > > compiler couldn't turn a "call wrapper(%rip)" into anything else.
> > >
> > > Actually, I think I have a better model - if the caller is done with inline asm.
> > >
> > > What you can do then is basically add a single-byte prefix to the
> > > "call" instruction that does nothing (say, cs override), and then
> > > replace *that* with a 'int3' instruction.
> > >
> > > Boom. Done.
> > >
> > > Now, the "int3" handler can just update the instruction in-place, but
> > > leave the "int3" in place, and then return to the next instruction
> > > byte (which is just the normal branch instruction without the prefix
> > > byte).
> > >
> > > The cross-CPU case continues to work, because the 'int3' remains in
> > > place until after the IPI.
> > 
> > Hmm, cute.  But then the calls are in inline asm, which results in
> > giant turds like we have for the pvop vcalls.  And, if they start
> > being used more generally, we potentially have ABI issues where the
> > calling convention isn't quite what the asm expects, and we explode.
> > 
> > I propose a different solution:
> > 
> > As in this patch set, we have a direct and an indirect version.  The
> > indirect version remains exactly the same as in this patch set.  The
> > direct version just only does the patching when all seems well: the
> > call instruction needs to be 0xe8, and we only do it when the thing
> > doesn't cross a cache line.  Does that work?  In the rare case where
> > the compiler generates something other than 0xe8 or crosses a cache
> > line, then the thing just remains as a call to the out of line jmp
> > trampoline.  Does that seem reasonable?  It's a very minor change to
> > the patch set.
> 
> Maybe that would be ok.  If my math is right, we would use the
> out-of-line version almost 5% of the time due to cache misalignment of
> the address.

BTW, this means that if any of a trampoline's callers crosses cache
boundaries then we won't be able to poison the trampoline.  Which is
kind of sad.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 22:14                                 ` Josh Poimboeuf
@ 2018-11-29 22:22                                   ` Peter Zijlstra
  2018-11-29 22:25                                     ` Andy Lutomirski
  0 siblings, 1 reply; 120+ messages in thread
From: Peter Zijlstra @ 2018-11-29 22:22 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Andy Lutomirski, Andy Lutomirski, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> > 
> > > > (like pointing IP at a stub that retpolines to the target by reading
> > > > the function pointer, a la the unoptimizable version), then okay, I
> > > > guess, with only a small amount of grumbling.
> > > 
> > > I tried that in v2, but Peter pointed out it's racy:
> > > 
> > >   https://lkml.kernel.org/r/20181126160217.GR2113@hirez.programming.kicks-ass.net
> > 
> > Ah, but that is because it is a global shared trampoline.
> > 
> > Each static_call has it's own trampoline; which currently reads
> > something like:
> > 
> > 	RETPOLINE_SAFE
> > 	JMP *key
> > 
> > which you then 'defuse' by writing an UD2 on. _However_, if you write
> > that trampoline like:
> > 
> > 1:	RETPOLINE_SAFE
> > 	JMP *key
> > 2:	CALL_NOSPEC *key
> > 	RET
> > 
> > and have the text_poke_bp() handler jump to 2 (a location you'll never
> > reach when you enter at 1), it will in fact work I think. The trampoline
> > is never modified and not shared between different static_call's.
> 
> But after returning from the function to the trampoline, how does it
> return from the trampoline to the call site?  At that point there is no
> return address on the stack.

Oh, right, so that RET don't work. ARGH. Time to go sleep I suppose.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 22:22                                   ` Peter Zijlstra
@ 2018-11-29 22:25                                     ` Andy Lutomirski
  2018-11-29 22:30                                       ` Josh Poimboeuf
  0 siblings, 1 reply; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-29 22:25 UTC (permalink / raw)
  To: Peter Zijlstra
  Cc: Josh Poimboeuf, Andrew Lutomirski, X86 ML, LKML, Ard Biesheuvel,
	Steven Rostedt, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 2:22 PM Peter Zijlstra <peterz@infradead.org> wrote:
>
> On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> > On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > > On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > > > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> > >
> > > > > (like pointing IP at a stub that retpolines to the target by reading
> > > > > the function pointer, a la the unoptimizable version), then okay, I
> > > > > guess, with only a small amount of grumbling.
> > > >
> > > > I tried that in v2, but Peter pointed out it's racy:
> > > >
> > > >   https://lkml.kernel.org/r/20181126160217.GR2113@hirez.programming.kicks-ass.net
> > >
> > > Ah, but that is because it is a global shared trampoline.
> > >
> > > Each static_call has it's own trampoline; which currently reads
> > > something like:
> > >
> > >     RETPOLINE_SAFE
> > >     JMP *key
> > >
> > > which you then 'defuse' by writing an UD2 on. _However_, if you write
> > > that trampoline like:
> > >
> > > 1:  RETPOLINE_SAFE
> > >     JMP *key
> > > 2:  CALL_NOSPEC *key
> > >     RET
> > >
> > > and have the text_poke_bp() handler jump to 2 (a location you'll never
> > > reach when you enter at 1), it will in fact work I think. The trampoline
> > > is never modified and not shared between different static_call's.
> >
> > But after returning from the function to the trampoline, how does it
> > return from the trampoline to the call site?  At that point there is no
> > return address on the stack.
>
> Oh, right, so that RET don't work. ARGH. Time to go sleep I suppose.

I assume I'm missing something, but can't it just be JMP_NOSPEC *key?
The code would call the trampoline just like any other function and,
if the alignment is bad, we can skip patching it.  And, if we want the
performance back, maybe some day we can find a clean way to patch
those misaligned callers, too.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 22:25                                     ` Andy Lutomirski
@ 2018-11-29 22:30                                       ` Josh Poimboeuf
  0 siblings, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-29 22:30 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Peter Zijlstra, X86 ML, LKML, Ard Biesheuvel, Steven Rostedt,
	Ingo Molnar, Thomas Gleixner, Linus Torvalds, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 02:25:33PM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 2:22 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > On Thu, Nov 29, 2018 at 04:14:46PM -0600, Josh Poimboeuf wrote:
> > > On Thu, Nov 29, 2018 at 11:01:48PM +0100, Peter Zijlstra wrote:
> > > > On Thu, Nov 29, 2018 at 11:10:50AM -0600, Josh Poimboeuf wrote:
> > > > > On Thu, Nov 29, 2018 at 08:59:31AM -0800, Andy Lutomirski wrote:
> > > >
> > > > > > (like pointing IP at a stub that retpolines to the target by reading
> > > > > > the function pointer, a la the unoptimizable version), then okay, I
> > > > > > guess, with only a small amount of grumbling.
> > > > >
> > > > > I tried that in v2, but Peter pointed out it's racy:
> > > > >
> > > > >   https://lkml.kernel.org/r/20181126160217.GR2113@hirez.programming.kicks-ass.net
> > > >
> > > > Ah, but that is because it is a global shared trampoline.
> > > >
> > > > Each static_call has it's own trampoline; which currently reads
> > > > something like:
> > > >
> > > >     RETPOLINE_SAFE
> > > >     JMP *key
> > > >
> > > > which you then 'defuse' by writing an UD2 on. _However_, if you write
> > > > that trampoline like:
> > > >
> > > > 1:  RETPOLINE_SAFE
> > > >     JMP *key
> > > > 2:  CALL_NOSPEC *key
> > > >     RET
> > > >
> > > > and have the text_poke_bp() handler jump to 2 (a location you'll never
> > > > reach when you enter at 1), it will in fact work I think. The trampoline
> > > > is never modified and not shared between different static_call's.
> > >
> > > But after returning from the function to the trampoline, how does it
> > > return from the trampoline to the call site?  At that point there is no
> > > return address on the stack.
> >
> > Oh, right, so that RET don't work. ARGH. Time to go sleep I suppose.
> 
> I assume I'm missing something, but can't it just be JMP_NOSPEC *key?
> The code would call the trampoline just like any other function and,
> if the alignment is bad, we can skip patching it.  And, if we want the
> performance back, maybe some day we can find a clean way to patch
> those misaligned callers, too.

Yeah, this is currently the leading contender, though I believe it will
use a direct jump like the current out-of-line implementation.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 20:24                                                 ` Josh Poimboeuf
  2018-11-29 22:17                                                   ` Josh Poimboeuf
@ 2018-11-29 23:04                                                   ` Linus Torvalds
  2018-11-30 16:27                                                     ` Josh Poimboeuf
  2018-12-12 18:29                                                     ` Josh Poimboeuf
  2018-11-30 16:42                                                   ` Andy Lutomirski
  2 siblings, 2 replies; 120+ messages in thread
From: Linus Torvalds @ 2018-11-29 23:04 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Andrew Lutomirski, Steven Rostedt, Peter Zijlstra,
	the arch/x86 maintainers, Linux List Kernel Mailing,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, mhiramat, jbaron,
	Jiri Kosina, David.Laight, bp, julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> >
> > I propose a different solution:
> >
> > As in this patch set, we have a direct and an indirect version.  The
> > indirect version remains exactly the same as in this patch set.  The
> > direct version just only does the patching when all seems well: the
> > call instruction needs to be 0xe8, and we only do it when the thing
> > doesn't cross a cache line.  Does that work?  In the rare case where
> > the compiler generates something other than 0xe8 or crosses a cache
> > line, then the thing just remains as a call to the out of line jmp
> > trampoline.  Does that seem reasonable?  It's a very minor change to
> > the patch set.
>
> Maybe that would be ok.  If my math is right, we would use the
> out-of-line version almost 5% of the time due to cache misalignment of
> the address.

Note that I don't think cache-line alignment is necessarily sufficient.

The I$ fetch from the cacheline can happen in smaller chunks, because
the bus between the I$ and the instruction decode isn't a full
cacheline (well, it is _now_ in modern big cores, but it hasn't always
been).

So even if the cacheline is updated atomically, I could imagine seeing
a partial fetch from the I$ (old values) and then a second partial
fetch (new values).

It would be interesting to know what the exact fetch rules are.

             Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 23:04                                                   ` Linus Torvalds
@ 2018-11-30 16:27                                                     ` Josh Poimboeuf
  2018-12-11  9:41                                                       ` David Laight
  2018-12-12 18:29                                                     ` Josh Poimboeuf
  1 sibling, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-30 16:27 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andrew Lutomirski, Steven Rostedt, Peter Zijlstra,
	the arch/x86 maintainers, Linux List Kernel Mailing,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, mhiramat, jbaron,
	Jiri Kosina, David.Laight, bp, julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 03:04:20PM -0800, Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> > >
> > > I propose a different solution:
> > >
> > > As in this patch set, we have a direct and an indirect version.  The
> > > indirect version remains exactly the same as in this patch set.  The
> > > direct version just only does the patching when all seems well: the
> > > call instruction needs to be 0xe8, and we only do it when the thing
> > > doesn't cross a cache line.  Does that work?  In the rare case where
> > > the compiler generates something other than 0xe8 or crosses a cache
> > > line, then the thing just remains as a call to the out of line jmp
> > > trampoline.  Does that seem reasonable?  It's a very minor change to
> > > the patch set.
> >
> > Maybe that would be ok.  If my math is right, we would use the
> > out-of-line version almost 5% of the time due to cache misalignment of
> > the address.
> 
> Note that I don't think cache-line alignment is necessarily sufficient.
> 
> The I$ fetch from the cacheline can happen in smaller chunks, because
> the bus between the I$ and the instruction decode isn't a full
> cacheline (well, it is _now_ in modern big cores, but it hasn't always
> been).
> 
> So even if the cacheline is updated atomically, I could imagine seeing
> a partial fetch from the I$ (old values) and then a second partial
> fetch (new values).
> 
> It would be interesting to know what the exact fetch rules are.

I've been doing  some cross-modifying code experiments on Nehalem, with
one CPU writing call destinations while the other CPUs are executing
them.  Reliably, one of the readers goes off into the weeds within a few
seconds.

The writing was done with just text_poke(), no #BP.

I wasn't able to figure out the pattern in the addresses of the
corrupted call sites.  It wasn't cache line.

That was on Nehalem.  Skylake didn't crash at all.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 20:24                                                 ` Josh Poimboeuf
  2018-11-29 22:17                                                   ` Josh Poimboeuf
  2018-11-29 23:04                                                   ` Linus Torvalds
@ 2018-11-30 16:42                                                   ` Andy Lutomirski
  2018-11-30 18:39                                                     ` Josh Poimboeuf
  2 siblings, 1 reply; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-30 16:42 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Andrew Lutomirski, Linus Torvalds, Steven Rostedt,
	Peter Zijlstra, X86 ML, LKML, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, Masami Hiramatsu, Jason Baron, Jiri Kosina,
	David Laight, Borislav Petkov, julia, jeyu, H. Peter Anvin

On Thu, Nov 29, 2018 at 12:24 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> > Alternatively, we could actually emulate call instructions like this:
> >
> > void __noreturn jump_to_kernel_pt_regs(struct pt_regs *regs, ...)
> > {
> >   struct pt_regs ptregs_copy = *regs;
> >   barrier();
> >   *(unsigned long *)(regs->sp - 8) = whatever;  /* may clobber old
> > regs, but so what? */
> >   asm volatile ("jmp return_to_alternate_ptregs");
> > }
> >
> > where return_to_alternate_ptregs points rsp to the ptregs and goes
> > through the normal return path.  It's ugly, but we could have a test
> > case for it, and it should work fine.
>
> Is that really any better than my patch to create a gap in the stack
> (modified for kernel space #BP only)?
>

I tend to prefer a nice local hack like mine over a hack that further
complicates the entry in general.  This is not to say I'm thrilled by
my idea either.

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-30 16:42                                                   ` Andy Lutomirski
@ 2018-11-30 18:39                                                     ` Josh Poimboeuf
  2018-11-30 19:45                                                       ` Linus Torvalds
  0 siblings, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-30 18:39 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Linus Torvalds, Steven Rostedt, Peter Zijlstra, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	jeyu, H. Peter Anvin

On Fri, Nov 30, 2018 at 08:42:26AM -0800, Andy Lutomirski wrote:
> On Thu, Nov 29, 2018 at 12:24 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > > Alternatively, we could actually emulate call instructions like this:
> > >
> > > void __noreturn jump_to_kernel_pt_regs(struct pt_regs *regs, ...)
> > > {
> > >   struct pt_regs ptregs_copy = *regs;
> > >   barrier();
> > >   *(unsigned long *)(regs->sp - 8) = whatever;  /* may clobber old
> > > regs, but so what? */
> > >   asm volatile ("jmp return_to_alternate_ptregs");
> > > }
> > >
> > > where return_to_alternate_ptregs points rsp to the ptregs and goes
> > > through the normal return path.  It's ugly, but we could have a test
> > > case for it, and it should work fine.
> >
> > Is that really any better than my patch to create a gap in the stack
> > (modified for kernel space #BP only)?
> >
> 
> I tend to prefer a nice local hack like mine over a hack that further
> complicates the entry in general.  This is not to say I'm thrilled by
> my idea either.

They're both mucking with the location of the pt_regs.  The above code
just takes that fact and hides it in the corner and hopes that there are
no bugs lurking there.

Even with the CPL check, the "gap" code is simple and self-contained
(see below).  The kernel pt_regs can already be anywhere on the stack so
there should be no harm in moving them.

AFAICT, all the other proposed options seem to have major issues.

diff --git a/arch/x86/entry/entry_64.S b/arch/x86/entry/entry_64.S
index ce25d84023c0..f487f7daed6c 100644
--- a/arch/x86/entry/entry_64.S
+++ b/arch/x86/entry/entry_64.S
@@ -876,7 +876,7 @@ apicinterrupt IRQ_WORK_VECTOR			irq_work_interrupt		smp_irq_work_interrupt
  * @paranoid == 2 is special: the stub will never switch stacks.  This is for
  * #DF: if the thread stack is somehow unusable, we'll still get a useful OOPS.
  */
-.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1
+.macro idtentry sym do_sym has_error_code:req paranoid=0 shift_ist=-1 create_gap=1
 ENTRY(\sym)
 	UNWIND_HINT_IRET_REGS offset=\has_error_code*8
 
@@ -896,6 +896,18 @@ ENTRY(\sym)
 	jnz	.Lfrom_usermode_switch_stack_\@
 	.endif
 
+#ifdef CONFIG_HAVE_STATIC_CALL_INLINE
+	.if \create_gap == 1
+	testb	$3, CS-ORIG_RAX(%rsp)
+	jnz	.Lfrom_usermode_no_gap_\@
+	.rept 6
+	pushq 5*8(%rsp)
+	.endr
+	UNWIND_HINT_IRET_REGS offset=8
+.Lfrom_usermode_no_gap_\@:
+	.endif
+#endif
+
 	.if \paranoid
 	call	paranoid_entry
 	.else
@@ -1126,7 +1138,7 @@ apicinterrupt3 HYPERV_STIMER0_VECTOR \
 #endif /* CONFIG_HYPERV */
 
 idtentry debug			do_debug		has_error_code=0	paranoid=1 shift_ist=DEBUG_STACK
-idtentry int3			do_int3			has_error_code=0
+idtentry int3			do_int3			has_error_code=0	create_gap=1
 idtentry stack_segment		do_stack_segment	has_error_code=1
 
 #ifdef CONFIG_XEN_PV

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-30 18:39                                                     ` Josh Poimboeuf
@ 2018-11-30 19:45                                                       ` Linus Torvalds
  2018-11-30 20:18                                                         ` Andy Lutomirski
  0 siblings, 1 reply; 120+ messages in thread
From: Linus Torvalds @ 2018-11-30 19:45 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Andrew Lutomirski, Steven Rostedt, Peter Zijlstra,
	the arch/x86 maintainers, Linux List Kernel Mailing,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, mhiramat, jbaron,
	Jiri Kosina, David.Laight, bp, julia, jeyu, Peter Anvin

On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
> AFAICT, all the other proposed options seem to have major issues.

I still absolutely detest this patch, and in fact it got worse from
the test of the config variable.

Honestly, the entry code being legible and simple is more important
than the extra cycle from branching to a trampoline for static calls.

Just don't do the inline case if it causes this much confusion.

             Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-30 19:45                                                       ` Linus Torvalds
@ 2018-11-30 20:18                                                         ` Andy Lutomirski
  2018-11-30 20:28                                                           ` Steven Rostedt
  2018-11-30 21:10                                                           ` Josh Poimboeuf
  0 siblings, 2 replies; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-30 20:18 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Josh Poimboeuf, Andrew Lutomirski, Steven Rostedt,
	Peter Zijlstra, X86 ML, LKML, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, Masami Hiramatsu, Jason Baron, Jiri Kosina,
	David Laight, Borislav Petkov, julia, jeyu, H. Peter Anvin

On Fri, Nov 30, 2018 at 11:51 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > AFAICT, all the other proposed options seem to have major issues.
>
> I still absolutely detest this patch, and in fact it got worse from
> the test of the config variable.
>
> Honestly, the entry code being legible and simple is more important
> than the extra cycle from branching to a trampoline for static calls.
>
> Just don't do the inline case if it causes this much confusion.

With my entry maintainer hat on, I don't mind it so much, although the
implementation needs some work.  The #ifdef should just go away, and
there should be another sanity check in the sanity check section.

Or we could replace that IPI with x86's bona fide serialize-all-cpus
primitive and then we can just retry instead of emulating.  It's a
piece of cake -- we just trigger an SMI :)  /me runs away.

--Andy

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-30 20:18                                                         ` Andy Lutomirski
@ 2018-11-30 20:28                                                           ` Steven Rostedt
  2018-11-30 20:59                                                             ` Andy Lutomirski
  2018-11-30 21:10                                                           ` Josh Poimboeuf
  1 sibling, 1 reply; 120+ messages in thread
From: Steven Rostedt @ 2018-11-30 20:28 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Linus Torvalds, Josh Poimboeuf, Peter Zijlstra, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	jeyu, H. Peter Anvin

On Fri, 30 Nov 2018 12:18:33 -0800
Andy Lutomirski <luto@kernel.org> wrote:

> Or we could replace that IPI with x86's bona fide serialize-all-cpus
> primitive and then we can just retry instead of emulating.  It's a
> piece of cake -- we just trigger an SMI :)  /me runs away.

I must have fallen on my head one too many times, because I really like
the idea of synchronizing all the CPUs with an SMI! (If that's even
possible). The IPI's that are sent are only to force smp_mb() on all
CPUs. Which should be something an SMI could do.

/me runs after Andy

-- Steve

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-30 20:28                                                           ` Steven Rostedt
@ 2018-11-30 20:59                                                             ` Andy Lutomirski
  2018-11-30 21:01                                                               ` Steven Rostedt
  2018-11-30 21:13                                                               ` Jiri Kosina
  0 siblings, 2 replies; 120+ messages in thread
From: Andy Lutomirski @ 2018-11-30 20:59 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Andrew Lutomirski, Linus Torvalds, Josh Poimboeuf,
	Peter Zijlstra, X86 ML, LKML, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, Masami Hiramatsu, Jason Baron, Jiri Kosina,
	David Laight, Borislav Petkov, julia, jeyu, H. Peter Anvin

On Fri, Nov 30, 2018 at 12:28 PM Steven Rostedt <rostedt@goodmis.org> wrote:
>
> On Fri, 30 Nov 2018 12:18:33 -0800
> Andy Lutomirski <luto@kernel.org> wrote:
>
> > Or we could replace that IPI with x86's bona fide serialize-all-cpus
> > primitive and then we can just retry instead of emulating.  It's a
> > piece of cake -- we just trigger an SMI :)  /me runs away.
>
> I must have fallen on my head one too many times, because I really like
> the idea of synchronizing all the CPUs with an SMI! (If that's even
> possible). The IPI's that are sent are only to force smp_mb() on all
> CPUs. Which should be something an SMI could do.
>
> /me runs after Andy

According to the SDM, you can program the APIC ICR to request an SMI.
It's not remotely clear to me what will happen if we do this.  For all
I know, the SMI handler will explode and the computer will catch fire.
PeterZ?

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-30 20:59                                                             ` Andy Lutomirski
@ 2018-11-30 21:01                                                               ` Steven Rostedt
  2018-11-30 21:13                                                               ` Jiri Kosina
  1 sibling, 0 replies; 120+ messages in thread
From: Steven Rostedt @ 2018-11-30 21:01 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Linus Torvalds, Josh Poimboeuf, Peter Zijlstra, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	jeyu, H. Peter Anvin

On Fri, 30 Nov 2018 12:59:36 -0800
Andy Lutomirski <luto@kernel.org> wrote:

> For all I know, the SMI handler will explode and the computer will catch fire.

That sounds like an AWESOME feature!!!

-- Steve


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-30 20:18                                                         ` Andy Lutomirski
  2018-11-30 20:28                                                           ` Steven Rostedt
@ 2018-11-30 21:10                                                           ` Josh Poimboeuf
  1 sibling, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-30 21:10 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Linus Torvalds, Steven Rostedt, Peter Zijlstra, X86 ML, LKML,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, Masami Hiramatsu,
	Jason Baron, Jiri Kosina, David Laight, Borislav Petkov, julia,
	jeyu, H. Peter Anvin

On Fri, Nov 30, 2018 at 12:18:33PM -0800, Andy Lutomirski wrote:
> On Fri, Nov 30, 2018 at 11:51 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > On Fri, Nov 30, 2018 at 10:39 AM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> > >
> > > AFAICT, all the other proposed options seem to have major issues.
> >
> > I still absolutely detest this patch, and in fact it got worse from
> > the test of the config variable.
> >
> > Honestly, the entry code being legible and simple is more important
> > than the extra cycle from branching to a trampoline for static calls.
> >
> > Just don't do the inline case if it causes this much confusion.

I *really* don't want to have to drop the inline feature.  The speedup
is measurable and not insignificant.  And out-of-line would be a
regression if we ported paravirt to use static calls.

> With my entry maintainer hat on, I don't mind it so much, although the
> implementation needs some work.  The #ifdef should just go away, and
> there should be another sanity check in the sanity check section.

Your suggested changes sound good to me.  I'll be gone next week, so
here's hoping you'll have this all figured out when I get back!

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-30 20:59                                                             ` Andy Lutomirski
  2018-11-30 21:01                                                               ` Steven Rostedt
@ 2018-11-30 21:13                                                               ` Jiri Kosina
  1 sibling, 0 replies; 120+ messages in thread
From: Jiri Kosina @ 2018-11-30 21:13 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Steven Rostedt, Linus Torvalds, Josh Poimboeuf, Peter Zijlstra,
	X86 ML, LKML, Ard Biesheuvel, Ingo Molnar, Thomas Gleixner,
	Masami Hiramatsu, Jason Baron, David Laight, Borislav Petkov,
	julia, jeyu, H. Peter Anvin

On Fri, 30 Nov 2018, Andy Lutomirski wrote:

> According to the SDM, you can program the APIC ICR to request an SMI. 
> It's not remotely clear to me what will happen if we do this.  

I think one of the known reliable ways to trigger SMI is to write 0x0 to 
the SMI command I/O port (0xb2).

> For all I know, the SMI handler will explode and the computer will catch 
> fire.

Ha, therefore noone can't claim any more that SMIs are always harmful :)

-- 
Jiri Kosina
SUSE Labs


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 19:22                                               ` Josh Poimboeuf
  2018-11-29 19:27                                                 ` Steven Rostedt
@ 2018-11-30 22:16                                                 ` Rasmus Villemoes
  2018-11-30 22:24                                                   ` Josh Poimboeuf
  1 sibling, 1 reply; 120+ messages in thread
From: Rasmus Villemoes @ 2018-11-30 22:16 UTC (permalink / raw)
  To: Josh Poimboeuf, Steven Rostedt
  Cc: Linus Torvalds, Andy Lutomirski, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On 29/11/2018 20.22, Josh Poimboeuf wrote:
> On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
>>> and honestly, the way "static_call()" works now, can you guarantee
>>> that the call-site doesn't end up doing that, and calling the
>>> trampoline function for two different static calls from one indirect
>>> call?
>>>
>>> See what I'm talking about? Saying "callers are wrapped in macros"
>>> doesn't actually protect you from the compiler doing things like that.
>>>
>>> In contrast, if the call was wrapped in an inline asm, we'd *know* the
>>> compiler couldn't turn a "call wrapper(%rip)" into anything else.
>>
>> But then we need to implement all numbers of parameters.
> 
> I actually have an old unfinished patch which (ab)used C macros to
> detect the number of parameters and then setup the asm constraints
> accordingly.  At the time, the goal was to optimize the BUG code.
> 
> I had wanted to avoid this kind of approach for static calls, because
> "ugh", but now it's starting to look much more appealing.
> 
> Behold:
> 
> diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
> index aa6b2023d8f8..d63e9240da77 100644
> --- a/arch/x86/include/asm/bug.h
> +++ b/arch/x86/include/asm/bug.h
> @@ -32,10 +32,59 @@
>  
>  #ifdef CONFIG_DEBUG_BUGVERBOSE
>  
> -#define _BUG_FLAGS(ins, flags)						\
> +#define __BUG_ARGS_0(ins, ...) \
> +({\
> +	asm volatile("1:\t" ins "\n"); \
> +})
> +#define __BUG_ARGS_1(ins, ...) \
> +({\
> +	asm volatile("1:\t" ins "\n" \
> +		     : : "D" (ARG1(__VA_ARGS__))); \
> +})
> +#define __BUG_ARGS_2(ins, ...) \
> +({\
> +	asm volatile("1:\t" ins "\n" \
> +		     : : "D" (ARG1(__VA_ARGS__)), \
> +			 "S" (ARG2(__VA_ARGS__))); \
> +})
> +#define __BUG_ARGS_3(ins, ...) \
> +({\
> +	asm volatile("1:\t" ins "\n" \
> +		     : : "D" (ARG1(__VA_ARGS__)), \
> +			 "S" (ARG2(__VA_ARGS__)), \
> +			 "d" (ARG3(__VA_ARGS__))); \
> +})

wouldn't you need to tie all these to (unused) outputs as well as adding
the remaining caller-saved registers to the clobber list? Maybe not for
the WARN machinery(?), but at least for stuff that should look like a
normal call to gcc? Then there's %rax which is either a clobber or an
output, and if there's not to be a separate static_call_void(), one
would need to do some __builtin_choose_expr(__same_type(void, f(...)), ...).

Rasmus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-30 22:16                                                 ` Rasmus Villemoes
@ 2018-11-30 22:24                                                   ` Josh Poimboeuf
  0 siblings, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-11-30 22:24 UTC (permalink / raw)
  To: Rasmus Villemoes
  Cc: Steven Rostedt, Linus Torvalds, Andy Lutomirski, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Fri, Nov 30, 2018 at 11:16:34PM +0100, Rasmus Villemoes wrote:
> On 29/11/2018 20.22, Josh Poimboeuf wrote:
> > On Thu, Nov 29, 2018 at 02:16:48PM -0500, Steven Rostedt wrote:
> >>> and honestly, the way "static_call()" works now, can you guarantee
> >>> that the call-site doesn't end up doing that, and calling the
> >>> trampoline function for two different static calls from one indirect
> >>> call?
> >>>
> >>> See what I'm talking about? Saying "callers are wrapped in macros"
> >>> doesn't actually protect you from the compiler doing things like that.
> >>>
> >>> In contrast, if the call was wrapped in an inline asm, we'd *know* the
> >>> compiler couldn't turn a "call wrapper(%rip)" into anything else.
> >>
> >> But then we need to implement all numbers of parameters.
> > 
> > I actually have an old unfinished patch which (ab)used C macros to
> > detect the number of parameters and then setup the asm constraints
> > accordingly.  At the time, the goal was to optimize the BUG code.
> > 
> > I had wanted to avoid this kind of approach for static calls, because
> > "ugh", but now it's starting to look much more appealing.
> > 
> > Behold:
> > 
> > diff --git a/arch/x86/include/asm/bug.h b/arch/x86/include/asm/bug.h
> > index aa6b2023d8f8..d63e9240da77 100644
> > --- a/arch/x86/include/asm/bug.h
> > +++ b/arch/x86/include/asm/bug.h
> > @@ -32,10 +32,59 @@
> >  
> >  #ifdef CONFIG_DEBUG_BUGVERBOSE
> >  
> > -#define _BUG_FLAGS(ins, flags)						\
> > +#define __BUG_ARGS_0(ins, ...) \
> > +({\
> > +	asm volatile("1:\t" ins "\n"); \
> > +})
> > +#define __BUG_ARGS_1(ins, ...) \
> > +({\
> > +	asm volatile("1:\t" ins "\n" \
> > +		     : : "D" (ARG1(__VA_ARGS__))); \
> > +})
> > +#define __BUG_ARGS_2(ins, ...) \
> > +({\
> > +	asm volatile("1:\t" ins "\n" \
> > +		     : : "D" (ARG1(__VA_ARGS__)), \
> > +			 "S" (ARG2(__VA_ARGS__))); \
> > +})
> > +#define __BUG_ARGS_3(ins, ...) \
> > +({\
> > +	asm volatile("1:\t" ins "\n" \
> > +		     : : "D" (ARG1(__VA_ARGS__)), \
> > +			 "S" (ARG2(__VA_ARGS__)), \
> > +			 "d" (ARG3(__VA_ARGS__))); \
> > +})
> 
> wouldn't you need to tie all these to (unused) outputs as well as adding
> the remaining caller-saved registers to the clobber list? Maybe not for
> the WARN machinery(?), but at least for stuff that should look like a
> normal call to gcc? Then there's %rax which is either a clobber or an
> output, and if there's not to be a separate static_call_void(), one
> would need to do some __builtin_choose_expr(__same_type(void, f(...)), ...).

Yes, this is a crappy unfinished patch.  It should be ignored, and
perhaps even mercilessly mocked :-)

paravirt_types.h already does something similar today, and it's at least
more correct than this.

What I was trying to show was that you can use macros to count
arguments, like this:

  _BUG_ARGS(ins, NUM_ARGS(__VA_ARGS__), __VA_ARGS__);

which can make a macro look and act like a function call.  Though as
Steven pointed out, the concept falls apart after 6 arguments.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-11-26 13:54 [PATCH v2 0/4] Static calls Josh Poimboeuf
                   ` (5 preceding siblings ...)
  2018-11-26 20:54 ` Steven Rostedt
@ 2018-12-04 23:08 ` Steven Rostedt
  2018-12-04 23:41   ` Andy Lutomirski
  2018-12-07 16:06 ` Edward Cree
  2018-12-10 23:57 ` Pavel Machek
  8 siblings, 1 reply; 120+ messages in thread
From: Steven Rostedt @ 2018-12-04 23:08 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Peter Zijlstra, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, Julia Cartwright, Jessica Yu, H. Peter Anvin


Where did this end up BTW?

I know that there's controversy about the
CONFIG_HAVE_STATIC_CALL_OPTIMIZED option, but I don't think the 
CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED version was controversial. From the
v1 patch 0 description:

There are three separate implementations, depending on what the arch
supports:

  1) CONFIG_HAVE_STATIC_CALL_OPTIMIZED: patched call sites - requires
     objtool and a small amount of arch code
  
  2) CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED: patched trampolines - requires
     a small amount of arch code
  
  3) If no arch support, fall back to regular function pointers

My benchmarks showed the best improvements with the
STATIC_CALL_OPTIMIZED, but it still showed improvement with the
UNOPTIMIZED version as well. Can we at least apply 2 and 3 from the
above (which happen to be the first part of the patch set. 1 comes in
at the end).

I would also just call it CONFIG_STATIC_CALL. If we every agree on the
optimized version, then we can call it CONFIG_STATIC_CALL_OPTIMIZED.
Have an option called UNOPTIMIZED just seems wrong.

-- Steve



On Mon, 26 Nov 2018 07:54:56 -0600
Josh Poimboeuf <jpoimboe@redhat.com> wrote:

> v2:
> - fix STATIC_CALL_TRAMP() macro by using __PASTE() [Ard]
> - rename optimized/unoptimized -> inline/out-of-line [Ard]
> - tweak arch interfaces for PLT and add key->tramp field [Ard]
> - rename 'poison' to 'defuse' and do it after all sites have been patched [Ard]
> - fix .init handling [Ard, Steven]
> - add CONFIG_HAVE_STATIC_CALL [Steven]
> - make interfaces more consistent across configs to allow tracepoints to
>   use them [Steven]
> - move __ADDRESSABLE() to static_call() macro [Steven]
> - prevent 2-byte jumps [Steven]
> - add offset to asm-offsets.c instead of hard coding key->func offset
> - add kernel_text_address() sanity check
> - make __ADDRESSABLE() symbols truly unique
> 
> TODO:
> - port Ard's arm64 patches to the new arch interfaces
> - tracepoint performance testing
> 
> --------------------
> 
> These patches are related to two similar patch sets from Ard and Steve:
> 
> - https://lkml.kernel.org/r/20181005081333.15018-1-ard.biesheuvel@linaro.org
> - https://lkml.kernel.org/r/20181006015110.653946300@goodmis.org
> 
> The code is also heavily inspired by the jump label code, as some of the
> concepts are very similar.
> 
> There are three separate implementations, depending on what the arch
> supports:
> 
>   1) CONFIG_HAVE_STATIC_CALL_INLINE: patched call sites - requires
>      objtool and a small amount of arch code
>   
>   2) CONFIG_HAVE_STATIC_CALL_OUTLINE: patched trampolines - requires
>      a small amount of arch code
>   
>   3) If no arch support, fall back to regular function pointers
> 
> 
> Josh Poimboeuf (4):
>   compiler.h: Make __ADDRESSABLE() symbol truly unique
>   static_call: Add static call infrastructure
>   x86/static_call: Add out-of-line static call implementation
>   x86/static_call: Add inline static call implementation for x86-64
> 
>  arch/Kconfig                                  |  10 +
>  arch/x86/Kconfig                              |   4 +-
>  arch/x86/include/asm/static_call.h            |  52 +++
>  arch/x86/kernel/Makefile                      |   1 +
>  arch/x86/kernel/asm-offsets.c                 |   6 +
>  arch/x86/kernel/static_call.c                 |  78 ++++
>  include/asm-generic/vmlinux.lds.h             |  11 +
>  include/linux/compiler.h                      |   2 +-
>  include/linux/module.h                        |  10 +
>  include/linux/static_call.h                   | 202 ++++++++++
>  include/linux/static_call_types.h             |  19 +
>  kernel/Makefile                               |   1 +
>  kernel/module.c                               |   5 +
>  kernel/static_call.c                          | 350 ++++++++++++++++++
>  tools/objtool/Makefile                        |   3 +-
>  tools/objtool/check.c                         | 126 ++++++-
>  tools/objtool/check.h                         |   2 +
>  tools/objtool/elf.h                           |   1 +
>  .../objtool/include/linux/static_call_types.h |  19 +
>  tools/objtool/sync-check.sh                   |   1 +
>  20 files changed, 899 insertions(+), 4 deletions(-)
>  create mode 100644 arch/x86/include/asm/static_call.h
>  create mode 100644 arch/x86/kernel/static_call.c
>  create mode 100644 include/linux/static_call.h
>  create mode 100644 include/linux/static_call_types.h
>  create mode 100644 kernel/static_call.c
>  create mode 100644 tools/objtool/include/linux/static_call_types.h
> 


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-04 23:08 ` Steven Rostedt
@ 2018-12-04 23:41   ` Andy Lutomirski
  2018-12-05 15:04     ` Josh Poimboeuf
  0 siblings, 1 reply; 120+ messages in thread
From: Andy Lutomirski @ 2018-12-04 23:41 UTC (permalink / raw)
  To: Steven Rostedt
  Cc: Josh Poimboeuf, x86, linux-kernel, Ard Biesheuvel,
	Andy Lutomirski, Peter Zijlstra, Ingo Molnar, Thomas Gleixner,
	Linus Torvalds, Masami Hiramatsu, Jason Baron, Jiri Kosina,
	David Laight, Borislav Petkov, Julia Cartwright, Jessica Yu,
	H. Peter Anvin



> On Dec 4, 2018, at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> 
> 
> Where did this end up BTW?
> 
> I know that there's controversy about the
> CONFIG_HAVE_STATIC_CALL_OPTIMIZED option, but I don't think the 
> CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED version was controversial. From the
> v1 patch 0 description:
> 
> There are three separate implementations, depending on what the arch
> supports:
> 
>  1) CONFIG_HAVE_STATIC_CALL_OPTIMIZED: patched call sites - requires
>     objtool and a small amount of arch code
> 
>  2) CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED: patched trampolines - requires
>     a small amount of arch code
> 
>  3) If no arch support, fall back to regular function pointers
> 
> My benchmarks showed the best improvements with the
> STATIC_CALL_OPTIMIZED, but it still showed improvement with the
> UNOPTIMIZED version as well. Can we at least apply 2 and 3 from the
> above (which happen to be the first part of the patch set. 1 comes in
> at the end).

Sounds good to me.

> 
> I would also just call it CONFIG_STATIC_CALL. If we every agree on the
> optimized version, then we can call it CONFIG_STATIC_CALL_OPTIMIZED.
> Have an option called UNOPTIMIZED just seems wrong.

My objection to all the bike shed colors so far is that we *always* have static_call() — it’s just not always static.

Anyway, I have a new objection to Josh’s create_gap proposal: what on Earth will kernel CET do to it?  Maybe my longjmp-like hack is actually better.



^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-04 23:41   ` Andy Lutomirski
@ 2018-12-05 15:04     ` Josh Poimboeuf
  2018-12-05 23:36       ` Andy Lutomirski
  0 siblings, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-12-05 15:04 UTC (permalink / raw)
  To: Andy Lutomirski
  Cc: Steven Rostedt, x86, linux-kernel, Ard Biesheuvel,
	Andy Lutomirski, Peter Zijlstra, Ingo Molnar, Thomas Gleixner,
	Linus Torvalds, Masami Hiramatsu, Jason Baron, Jiri Kosina,
	David Laight, Borislav Petkov, Julia Cartwright, Jessica Yu,
	H. Peter Anvin

On Tue, Dec 04, 2018 at 03:41:01PM -0800, Andy Lutomirski wrote:
> 
> 
> > On Dec 4, 2018, at 3:08 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
> > 
> > 
> > Where did this end up BTW?
> > 
> > I know that there's controversy about the
> > CONFIG_HAVE_STATIC_CALL_OPTIMIZED option, but I don't think the 
> > CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED version was controversial. From the
> > v1 patch 0 description:
> > 
> > There are three separate implementations, depending on what the arch
> > supports:
> > 
> >  1) CONFIG_HAVE_STATIC_CALL_OPTIMIZED: patched call sites - requires
> >     objtool and a small amount of arch code
> > 
> >  2) CONFIG_HAVE_STATIC_CALL_UNOPTIMIZED: patched trampolines - requires
> >     a small amount of arch code
> > 
> >  3) If no arch support, fall back to regular function pointers
> > 
> > My benchmarks showed the best improvements with the
> > STATIC_CALL_OPTIMIZED, but it still showed improvement with the
> > UNOPTIMIZED version as well. Can we at least apply 2 and 3 from the
> > above (which happen to be the first part of the patch set. 1 comes in
> > at the end).
> 
> Sounds good to me.
> 
> > 
> > I would also just call it CONFIG_STATIC_CALL. If we every agree on the
> > optimized version, then we can call it CONFIG_STATIC_CALL_OPTIMIZED.
> > Have an option called UNOPTIMIZED just seems wrong.

(Poking my head up for a bit, soon to disappear again until next week)

Ard had already objected to "unoptimized", which was why for v2 I
renamed them to CONFIG_STATIC_CALL_OUTLINE and CONFIG_STATIC_CALL_INLINE.

I could rename it to CONFIG_STATIC_CALL and CONFIG_STATIC_CALL_INLINE if
you prefer.  I don't have much of an opinion either way.

I'll post a v3 next week or so, with the controversial bits more fully
separated from the non-controversial bits.  So at least the out-of-line
implementation can get merged.

> My objection to all the bike shed colors so far is that we *always*
> have static_call() — it’s just not always static.

Hm?  Do you mean you don't like that we have a generic function pointer
implementation?  or what?

> Anyway, I have a new objection to Josh’s create_gap proposal: what on
> Earth will kernel CET do to it?  Maybe my longjmp-like hack is
> actually better.

Does CET even care about iret?  I assumed it didn't.  If it does, your
proposal would have the same problem, no?

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-05 15:04     ` Josh Poimboeuf
@ 2018-12-05 23:36       ` Andy Lutomirski
  0 siblings, 0 replies; 120+ messages in thread
From: Andy Lutomirski @ 2018-12-05 23:36 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: Steven Rostedt, X86 ML, LKML, Ard Biesheuvel, Andrew Lutomirski,
	Peter Zijlstra, Ingo Molnar, Thomas Gleixner, Linus Torvalds,
	Masami Hiramatsu, Jason Baron, Jiri Kosina, David Laight,
	Borislav Petkov, julia, jeyu, H. Peter Anvin

>> On Dec 5, 2018, at 7:04 AM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
>
>
>> Anyway, I have a new objection to Josh’s create_gap proposal: what on
>> Earth will kernel CET do to it?  Maybe my longjmp-like hack is
>> actually better.
>
> Does CET even care about iret?  I assumed it didn't.  If it does, your
> proposal would have the same problem, no?

I think it doesn’t, but it doesn’t really matter.  The shadow stack looks like:

retaddr of function being poked
call do_int3 + 5

And, to emulate a call, you need to stick a new frame right in the
middle.  At least with a longjmp-like approach, you can clobber the
“call do_int3 + 5” part and then INCSSP on the way out.  To be fair, I
think this also sucks.

PeterZ, can we abuse NMI to make this problem go away?  I don't
suppose that we have some rule that NMI handlers never wait for other
CPUs to finish doing anything?

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-11-26 13:54 [PATCH v2 0/4] Static calls Josh Poimboeuf
                   ` (6 preceding siblings ...)
  2018-12-04 23:08 ` Steven Rostedt
@ 2018-12-07 16:06 ` Edward Cree
  2018-12-07 16:49   ` Edward Cree
  2018-12-11 18:05   ` Josh Poimboeuf
  2018-12-10 23:57 ` Pavel Machek
  8 siblings, 2 replies; 120+ messages in thread
From: Edward Cree @ 2018-12-07 16:06 UTC (permalink / raw)
  To: Josh Poimboeuf; +Cc: linux-kernel, x86, Paolo Abeni

Sorry if this has been pointed out before (it's a very long thread), but
 in the out-of-line implementation, it appears that static_call_update()
 never alters key->func.  Am I right in thinking that this should be
 fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to
 arch_static_call_transform() on line 159 of include/linux/static_call.h?

Some background (why does key->func matter for the
 CONFIG_HAVE_STATIC_CALL_OUTLINE case?): I am experimenting with
 combining these static calls with the 'indirect call wrappers' notion
 that Paolo Abeni has been working on [1], using runtime instrumentation
 to determine a list of potential callees.  (This allows us to cope with
 cases where the callees are in modules, or where different workloads may
 use different sets of callees for a given call site, neither of which is
 handled by Paolo's approach).
The core of my design looks something like:

static int dynamic_call_xyz(int (*func)(some_args), some_args)
{
	if (func == dynamic_call_xyz_1.func)
		return static_call(dynamic_call_xyz_1, some_args);
	if (func == dynamic_call_xyz_2.func)
		return static_call(dynamic_call_xyz_2, some_args);
	return (*func)(some_args);
}

albeit with a bunch of extra (and currently rather ugly) stuff to collect
 the statistics needed to decide what to put in the static call keys, and
 mechanisms (RCU in my current case) to ensure that the static call isn't
 changed between checking its .func and actually calling it.

-Ed

PS: not on list, please keep me in CC.

[1] https://lwn.net/Articles/773985/

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-07 16:06 ` Edward Cree
@ 2018-12-07 16:49   ` Edward Cree
  2018-12-11 18:05   ` Josh Poimboeuf
  1 sibling, 0 replies; 120+ messages in thread
From: Edward Cree @ 2018-12-07 16:49 UTC (permalink / raw)
  To: Josh Poimboeuf; +Cc: linux-kernel, x86, Paolo Abeni

On 07/12/18 16:06, Edward Cree wrote:
> Sorry if this has been pointed out before (it's a very long thread), but
>  in the out-of-line implementation, it appears that static_call_update()
>  never alters key->func.  Am I right in thinking that this should be
>  fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to
>  arch_static_call_transform() on line 159 of include/linux/static_call.h?
On further examination, it's worse than that.

Why does the CONFIG_HAVE_STATIC_CALL_OUTLINE static_call_update() not
 call __static_call_update()?  It contains nothing but a BUILD_BUG_ON,
 which isn't likely to update anything.

-Ed

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-11-26 13:54 [PATCH v2 0/4] Static calls Josh Poimboeuf
                   ` (7 preceding siblings ...)
  2018-12-07 16:06 ` Edward Cree
@ 2018-12-10 23:57 ` Pavel Machek
  8 siblings, 0 replies; 120+ messages in thread
From: Pavel Machek @ 2018-12-10 23:57 UTC (permalink / raw)
  To: Josh Poimboeuf
  Cc: x86, linux-kernel, Ard Biesheuvel, Andy Lutomirski,
	Steven Rostedt, Peter Zijlstra, Ingo Molnar, Thomas Gleixner,
	Linus Torvalds, Masami Hiramatsu, Jason Baron, Jiri Kosina,
	David Laight, Borislav Petkov, Julia Cartwright, Jessica Yu,
	H. Peter Anvin

[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]

Hi!

> These patches are related to two similar patch sets from Ard and Steve:
> 
> - https://lkml.kernel.org/r/20181005081333.15018-1-ard.biesheuvel@linaro.org
> - https://lkml.kernel.org/r/20181006015110.653946300@goodmis.org
> 
> The code is also heavily inspired by the jump label code, as some of the
> concepts are very similar.
> 
> There are three separate implementations, depending on what the arch
> supports:
> 
>   1) CONFIG_HAVE_STATIC_CALL_INLINE: patched call sites - requires
>      objtool and a small amount of arch code
>   
>   2) CONFIG_HAVE_STATIC_CALL_OUTLINE: patched trampolines - requires
>      a small amount of arch code
>   
>   3) If no arch support, fall back to regular function pointers

Well, it would be nice to mention what these patches do :-).

I guess they are expected to make things slightly faster? If so it
would be nice to mention benchmarks...

(There are even statistics later in the series, but I guess at least
short explanation should be in cover letter).

								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 19:11                                               ` Linus Torvalds
@ 2018-12-10 23:58                                                 ` Pavel Machek
  2018-12-11  1:43                                                   ` Linus Torvalds
  0 siblings, 1 reply; 120+ messages in thread
From: Pavel Machek @ 2018-12-10 23:58 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Steven Rostedt, Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

[-- Attachment #1: Type: text/plain, Size: 885 bytes --]

On Thu 2018-11-29 11:11:50, Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 11:08 AM Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> >
> > What you can do then is basically add a single-byte prefix to the
> > "call" instruction that does nothing (say, cs override), and then
> > replace *that* with a 'int3' instruction.
> 
> Hmm. the segment prefixes are documented as being "reserved" for
> branch instructions. I *think* that means just conditional branches
> (Intel at one point used the prefixes for static prediction
> information), not "call", but who knows..
> 
> It might be better to use an empty REX prefix on x86-64 or something like that.

It might be easiest to use plain old NOP, no? :-).
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-12-10 23:58                                                 ` Pavel Machek
@ 2018-12-11  1:43                                                   ` Linus Torvalds
  0 siblings, 0 replies; 120+ messages in thread
From: Linus Torvalds @ 2018-12-11  1:43 UTC (permalink / raw)
  To: pavel
  Cc: Steven Rostedt, Andy Lutomirski, Josh Poimboeuf, Peter Zijlstra,
	Andrew Lutomirski, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, David.Laight, bp,
	julia, jeyu, Peter Anvin

On Mon, Dec 10, 2018 at 3:58 PM Pavel Machek <pavel@ucw.cz> wrote:
>
> On Thu 2018-11-29 11:11:50, Linus Torvalds wrote:
> >
> > It might be better to use an empty REX prefix on x86-64 or something like that.
>
> It might be easiest to use plain old NOP, no? :-).

No. The whole point would be that the instruction rewriting is atomic wrt fetch.

If it's a "nop" + "second instruction", and the "nop" is overwritten
by "int3", then the second instruction could still be executed after
the "int3" has been written (because the other CPU just finished the
"nop".

So an empty rex prefix is very different from a one-byte nop, exactly
because it's executed atomically with the instruction itself.

              Linus

^ permalink raw reply	[flat|nested] 120+ messages in thread

* RE: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-30 16:27                                                     ` Josh Poimboeuf
@ 2018-12-11  9:41                                                       ` David Laight
  2018-12-11 17:19                                                         ` Josh Poimboeuf
  0 siblings, 1 reply; 120+ messages in thread
From: David Laight @ 2018-12-11  9:41 UTC (permalink / raw)
  To: 'Josh Poimboeuf', Linus Torvalds
  Cc: Andrew Lutomirski, Steven Rostedt, Peter Zijlstra,
	the arch/x86 maintainers, Linux List Kernel Mailing,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, mhiramat, jbaron,
	Jiri Kosina, bp, julia, jeyu, Peter Anvin

From: Josh Poimboeuf
> Sent: 30 November 2018 16:27
> 
> On Thu, Nov 29, 2018 at 03:04:20PM -0800, Linus Torvalds wrote:
> > On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
...
> > > Maybe that would be ok.  If my math is right, we would use the
> > > out-of-line version almost 5% of the time due to cache misalignment of
> > > the address.
> >
> > Note that I don't think cache-line alignment is necessarily sufficient.
> >
> > The I$ fetch from the cacheline can happen in smaller chunks, because
> > the bus between the I$ and the instruction decode isn't a full
> > cacheline (well, it is _now_ in modern big cores, but it hasn't always
> > been).
> >
> > So even if the cacheline is updated atomically, I could imagine seeing
> > a partial fetch from the I$ (old values) and then a second partial
> > fetch (new values).
> >
> > It would be interesting to know what the exact fetch rules are.
> 
> I've been doing  some cross-modifying code experiments on Nehalem, with
> one CPU writing call destinations while the other CPUs are executing
> them.  Reliably, one of the readers goes off into the weeds within a few
> seconds.
> 
> The writing was done with just text_poke(), no #BP.
> 
> I wasn't able to figure out the pattern in the addresses of the
> corrupted call sites.  It wasn't cache line.
> 
> That was on Nehalem.  Skylake didn't crash at all.

Interesting thought?

If it is possible to add a prefix that can be overwritten by an int3
is it also possible to add something that the assembler will use
to align the instruction so that a write to the 4 byte offset
will be atomic?

I'd guess that avoiding 8 byte granularity would be sufficient.
So you'd need a 1, 2 or 3 byte nop depending on the actual
alignment - although a 3 byte one would always do.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-12-11  9:41                                                       ` David Laight
@ 2018-12-11 17:19                                                         ` Josh Poimboeuf
  0 siblings, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-12-11 17:19 UTC (permalink / raw)
  To: David Laight
  Cc: Linus Torvalds, Andrew Lutomirski, Steven Rostedt,
	Peter Zijlstra, the arch/x86 maintainers,
	Linux List Kernel Mailing, Ard Biesheuvel, Ingo Molnar,
	Thomas Gleixner, mhiramat, jbaron, Jiri Kosina, bp, julia, jeyu,
	Peter Anvin

On Tue, Dec 11, 2018 at 09:41:37AM +0000, David Laight wrote:
> From: Josh Poimboeuf
> > Sent: 30 November 2018 16:27
> > 
> > On Thu, Nov 29, 2018 at 03:04:20PM -0800, Linus Torvalds wrote:
> > > On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> ...
> > > > Maybe that would be ok.  If my math is right, we would use the
> > > > out-of-line version almost 5% of the time due to cache misalignment of
> > > > the address.
> > >
> > > Note that I don't think cache-line alignment is necessarily sufficient.
> > >
> > > The I$ fetch from the cacheline can happen in smaller chunks, because
> > > the bus between the I$ and the instruction decode isn't a full
> > > cacheline (well, it is _now_ in modern big cores, but it hasn't always
> > > been).
> > >
> > > So even if the cacheline is updated atomically, I could imagine seeing
> > > a partial fetch from the I$ (old values) and then a second partial
> > > fetch (new values).
> > >
> > > It would be interesting to know what the exact fetch rules are.
> > 
> > I've been doing  some cross-modifying code experiments on Nehalem, with
> > one CPU writing call destinations while the other CPUs are executing
> > them.  Reliably, one of the readers goes off into the weeds within a few
> > seconds.
> > 
> > The writing was done with just text_poke(), no #BP.
> > 
> > I wasn't able to figure out the pattern in the addresses of the
> > corrupted call sites.  It wasn't cache line.
> > 
> > That was on Nehalem.  Skylake didn't crash at all.
> 
> Interesting thought?
> 
> If it is possible to add a prefix that can be overwritten by an int3
> is it also possible to add something that the assembler will use
> to align the instruction so that a write to the 4 byte offset
> will be atomic?
> 
> I'd guess that avoiding 8 byte granularity would be sufficient.
> So you'd need a 1, 2 or 3 byte nop depending on the actual
> alignment - although a 3 byte one would always do.

The problem is that the call is done in C code, and we don't have a
feasible way to use inline asm to call functions with more than five
arguments.

BTW, my original experiments (mentioned above) were a bit... flawed.  I
used text_poke(), which does memcpy(), which writes one byte at a time.
No wonder it wasn't atomic.

I'll need to do some more experiments.

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-07 16:06 ` Edward Cree
  2018-12-07 16:49   ` Edward Cree
@ 2018-12-11 18:05   ` Josh Poimboeuf
  2018-12-12  5:59     ` Nadav Amit
  1 sibling, 1 reply; 120+ messages in thread
From: Josh Poimboeuf @ 2018-12-11 18:05 UTC (permalink / raw)
  To: Edward Cree; +Cc: linux-kernel, x86, Paolo Abeni, Nadav Amit

On Fri, Dec 07, 2018 at 04:06:32PM +0000, Edward Cree wrote:
> Sorry if this has been pointed out before (it's a very long thread), but
>  in the out-of-line implementation, it appears that static_call_update()
>  never alters key->func.  Am I right in thinking that this should be
>  fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to
>  arch_static_call_transform() on line 159 of include/linux/static_call.h?

Yes, you're right about both bugs in the out-of-line case: key->func
needs to be written, and __static_call_update() needs to be called by
static_call_update.  I was so focused on getting the inline case working
that I overlooked those.

> Some background (why does key->func matter for the
>  CONFIG_HAVE_STATIC_CALL_OUTLINE case?): I am experimenting with
>  combining these static calls with the 'indirect call wrappers' notion
>  that Paolo Abeni has been working on [1], using runtime instrumentation
>  to determine a list of potential callees.  (This allows us to cope with
>  cases where the callees are in modules, or where different workloads may
>  use different sets of callees for a given call site, neither of which is
>  handled by Paolo's approach).
> The core of my design looks something like:
> 
> static int dynamic_call_xyz(int (*func)(some_args), some_args)
> {
> 	if (func == dynamic_call_xyz_1.func)
> 		return static_call(dynamic_call_xyz_1, some_args);
> 	if (func == dynamic_call_xyz_2.func)
> 		return static_call(dynamic_call_xyz_2, some_args);
> 	return (*func)(some_args);
> }
> 
> albeit with a bunch of extra (and currently rather ugly) stuff to collect
>  the statistics needed to decide what to put in the static call keys, and
>  mechanisms (RCU in my current case) to ensure that the static call isn't
>  changed between checking its .func and actually calling it.
> 
> -Ed
> 
> PS: not on list, please keep me in CC.
> 
> [1] https://lwn.net/Articles/773985/

Thanks, this sounds very interesting.  Adding Nadav to CC, as he has
been looking at a different approach to solving the same problem:

  https://lkml.kernel.org/r/20181018005420.82993-1-namit@vmware.com

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-11 18:05   ` Josh Poimboeuf
@ 2018-12-12  5:59     ` Nadav Amit
  2018-12-12 17:11       ` Edward Cree
  0 siblings, 1 reply; 120+ messages in thread
From: Nadav Amit @ 2018-12-12  5:59 UTC (permalink / raw)
  To: Josh Poimboeuf; +Cc: Edward Cree, LKML, x86, Paolo Abeni

> On Dec 11, 2018, at 10:05 AM, Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> 
> On Fri, Dec 07, 2018 at 04:06:32PM +0000, Edward Cree wrote:
>> Sorry if this has been pointed out before (it's a very long thread), but
>> in the out-of-line implementation, it appears that static_call_update()
>> never alters key->func.  Am I right in thinking that this should be
>> fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to
>> arch_static_call_transform() on line 159 of include/linux/static_call.h?
> 
> Yes, you're right about both bugs in the out-of-line case: key->func
> needs to be written, and __static_call_update() needs to be called by
> static_call_update.  I was so focused on getting the inline case working
> that I overlooked those.
> 
>> Some background (why does key->func matter for the
>> CONFIG_HAVE_STATIC_CALL_OUTLINE case?): I am experimenting with
>> combining these static calls with the 'indirect call wrappers' notion
>> that Paolo Abeni has been working on [1], using runtime instrumentation
>> to determine a list of potential callees.  (This allows us to cope with
>> cases where the callees are in modules, or where different workloads may
>> use different sets of callees for a given call site, neither of which is
>> handled by Paolo's approach).
>> The core of my design looks something like:
>> 
>> static int dynamic_call_xyz(int (*func)(some_args), some_args)
>> {
>> 	if (func == dynamic_call_xyz_1.func)
>> 		return static_call(dynamic_call_xyz_1, some_args);
>> 	if (func == dynamic_call_xyz_2.func)
>> 		return static_call(dynamic_call_xyz_2, some_args);
>> 	return (*func)(some_args);
>> }
>> 
>> albeit with a bunch of extra (and currently rather ugly) stuff to collect
>> the statistics needed to decide what to put in the static call keys, and
>> mechanisms (RCU in my current case) to ensure that the static call isn't
>> changed between checking its .func and actually calling it.
>> 
>> -Ed
>> 
>> PS: not on list, please keep me in CC.
>> 
>> [1] https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flwn.net%2FArticles%2F773985%2F&amp;data=02%7C01%7Cnamit%40vmware.com%7C147894d6c56d4ce6c1fc08d65f933adf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636801483286688490&amp;sdata=QOZcfWXjvPqoR0oujtf1QTQLenv%2BiEu6jUA5fiav6Mo%3D&amp;reserved=0
> 
> Thanks, this sounds very interesting.  Adding Nadav to CC, as he has
> been looking at a different approach to solving the same problem:
> 
>  https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flkml.kernel.org%2Fr%2F20181018005420.82993-1-namit%40vmware.com&amp;data=02%7C01%7Cnamit%40vmware.com%7C147894d6c56d4ce6c1fc08d65f933adf%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636801483286688490&amp;sdata=bCI2N2xKUVyyyPAnWDH3mC3DsSk%2Bzy5nmI0DV%2F%2FaYYw%3D&amp;reserved=0

Thanks for cc’ing me. (I didn’t know about the other patch-sets.)

Allow me to share my experience, because I was studying this issue for some
time and have implemented more than I shared, since the code need more
cleanup. Some of the proposed approaches are things we either considered or
actually implemented (and later dropped). Eventually, our design was guided
by performance profiling and a grain of “what’s academic” consideration.

I think that eventually you would want to go with one central mechanism for
the various situations:

1. Registered targets (static) and automatically learnt targets (dynamic).
Registration does not work in some cases (e.g., file-system function
pointers, there are too many of those). On the other hand, if you know your
target it is obviously simpler/better.

2. With/without retpoline fallback. We’ve have always had the retpoline as
fallback, but if you use a registration mechanism, it’s not necessary.

3. Single and multiple targets. For multiple targets we decided to use
outline block in order not to inflate the code for no reason. There were
over 10000 indirect branches in our kernel build, but in our workloads only
~500 were actually run.

If you got with the approach that Edward mentioned, you may want to
associate each “function" with identifier (think about file_operations
having an additional field that holds a unique ID, or using the struct
address). This would allow you to use a “binary search” to find the right
target, which would be slightly more efficient. We actually used a
binary-search for a different reason - learning the most frequent syscalls
per process and calling them in this manner (we actually had an indirection
table to choose the right one).

3. Call-chains which are mostly fixed (next). You want to unroll those.

4. Per-process calls. The case that bothered us the most is seccomp. On our
setup, systemd installed 17(!) BPF seccomp programs on Redis server, causing
every syscall to go through 17 indirect branches to invoke them. But
similarly you have mmu-notifiers and others. We used a per-process
trampoline page for this matter.

Now there is of course the question of whether to go through automatic
inference of the indirect call sites (using asm macros/GCC plugin) or
manually marking them (using C macros). Initially we used C macros, which we
created using semi-automatically generated Coccinelle scripts. As I
remembered how I was crucified in the past over “uglification” of the code,
I thought a transparent modification of the code would be better, so we went
with asm macros for our prototype.

Finally, I should mention that the impact of most of these mechanisms should
not be significant (or even positive) if retpolines were not used. Having
said that, the automatically-learnt indirect branch promotion (with a single
target) showed up to roughly 2% performance improvement.

Please let me know how you want to proceed. I didn’t know about your
patch-set, but I think that having two similar (yet different) separate
mechanisms is not great. If you want, I’ll finish addressing the issues
you’ve raised and send another RFC.

Regards,
Nadav

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-12  5:59     ` Nadav Amit
@ 2018-12-12 17:11       ` Edward Cree
  2018-12-12 17:47         ` [RFC/WIP PATCH 0/2] dynamic calls Edward Cree
  2018-12-12 18:14         ` [PATCH v2 0/4] Static calls Nadav Amit
  0 siblings, 2 replies; 120+ messages in thread
From: Edward Cree @ 2018-12-12 17:11 UTC (permalink / raw)
  To: Nadav Amit, Josh Poimboeuf; +Cc: LKML, x86, Paolo Abeni

On 12/12/18 05:59, Nadav Amit wrote:
> Thanks for cc’ing me. (I didn’t know about the other patch-sets.)
Well in my case, that's because I haven't posted any yet.  (Will follow up
 shortly with what I currently have, though it's not pretty.)

Looking at your patches, it seems you've got a much more developed learning
 mechanism.  Mine on the other hand is brutally simple but runs continuously
 (i.e. after we patch we immediately enter the next 'relearning' phase);
 since it never does anything but prod a handful of percpu variables, this
 shouldn't be too costly.

Also, you've got the macrology for making all indirect calls use this,
 whereas at present I just have an open-coded instance on a single call site
 (I went with deliver_skb in the networking stack).

So I think where we probably want to go from here is:
 1) get Josh's static_calls in.  AIUI Linus seems to prefer the out-of-line
    approach; I'd say ditch the inline version (at least for now).
 2) build a relpolines patch series that uses
   i) static_calls for the text-patching part
  ii) as much of Nadav's macrology as is applicable
 iii) either my or Nadav's learning mechanism; we can experiment with both,
      bikeshed it incessantly etc.

Seem reasonable?

-Ed

^ permalink raw reply	[flat|nested] 120+ messages in thread

* [RFC/WIP PATCH 0/2] dynamic calls
  2018-12-12 17:11       ` Edward Cree
@ 2018-12-12 17:47         ` Edward Cree
  2018-12-12 17:50           ` [RFC PATCH 1/2] static_call: fix out-of-line static call implementation Edward Cree
  2018-12-12 17:52           ` [RFC PATCH 2/2] net: core: rather hacky PoC implementation of dynamic calls Edward Cree
  2018-12-12 18:14         ` [PATCH v2 0/4] Static calls Nadav Amit
  1 sibling, 2 replies; 120+ messages in thread
From: Edward Cree @ 2018-12-12 17:47 UTC (permalink / raw)
  To: Nadav Amit, Josh Poimboeuf; +Cc: linux-kernel, x86, Paolo Abeni

A fix to the static_calls series (on which this series depends), and a really
 hacky proof-of-concept of runtime-patched branch trees of static_calls to
 avoid indirect calls / retpolines in the hot-path.  Rather than any generally
 applicable machinery, the patch just open-codes it for one call site (the
 pt_prev->func() call in deliver_skb and __netif_receive_skb_one_core()); it
 should however be possible to make a macro that takes a 'name' parameter and
 expands to the whole thing.  Also the _update() function could be shared and
 get something useful from its work_struct, rather than needing a separate
 copy of the function for every indirect call site.

Performance testing so far has been somewhat inconclusive; I applied this on
 net-next, hacked up my Kconfig to use out-of-line static calls on x86-64, and
 ran some 1-byte UDP stream tests with the DUT receiving.
On a single stream test, I saw packet rate go up by 7%, from 470Kpps to
 504Kpps, with a considerable reduction in variance; however, CPU usage
 increased by a larger factor: (packet rate / RX cpu) is a much lower-variance
 measurement and went down by 13%.  This however may be because it often got
 into a state where, while patching the calls (and thus sending all callers
 down the slow path) we continue to gather stats and see enough calls to
 trigger another update; as there's no code to detect and skip an update that
 doesn't change anything, we get into a tight loop of redoing updates.  I am
 working on this & plan to change it to not collect any stats while an update
 is actually in progress.
On a 4-stream test, the variance I saw was too high to draw any conclusions;
 the packet rate went down about 2½% but this was not statistically
 significant (and the fastest run I saw was with dynamic calls present).

Edward Cree (2):
  static_call: fix out-of-line static call implementation
  net: core: rather hacky PoC implementation of dynamic calls

 include/linux/static_call.h |   6 +-
 net/core/dev.c              | 222 +++++++++++++++++++++++++++++++++++++++++++-
 2 files changed, 221 insertions(+), 7 deletions(-)


^ permalink raw reply	[flat|nested] 120+ messages in thread

* [RFC PATCH 1/2] static_call: fix out-of-line static call implementation
  2018-12-12 17:47         ` [RFC/WIP PATCH 0/2] dynamic calls Edward Cree
@ 2018-12-12 17:50           ` Edward Cree
  2018-12-12 17:52           ` [RFC PATCH 2/2] net: core: rather hacky PoC implementation of dynamic calls Edward Cree
  1 sibling, 0 replies; 120+ messages in thread
From: Edward Cree @ 2018-12-12 17:50 UTC (permalink / raw)
  To: Nadav Amit, Josh Poimboeuf; +Cc: linux-kernel, x86, Paolo Abeni

Actually call __static_call_update() from static_call_update(), and fix the
 former so it can actually compile.  Also make it update key.func.

Signed-off-by: Edward Cree <ecree@solarflare.com>
---
 include/linux/static_call.h | 6 ++++--
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/include/linux/static_call.h b/include/linux/static_call.h
index 6daff586c97d..38d6c1e4c85d 100644
--- a/include/linux/static_call.h
+++ b/include/linux/static_call.h
@@ -153,16 +153,18 @@ struct static_call_key {
 
 #define static_call(key, args...) STATIC_CALL_TRAMP(key)(args)
 
-#define __static_call_update(key, func)					\
+#define __static_call_update(key, _func)				\
 ({									\
 	cpus_read_lock();						\
-	arch_static_call_transform(NULL, key->tramp, func);		\
+	arch_static_call_transform(NULL, key.tramp, _func);		\
+	WRITE_ONCE(key.func, _func);					\
 	cpus_read_unlock();						\
 })
 
 #define static_call_update(key, func)					\
 ({									\
 	BUILD_BUG_ON(!__same_type(func, STATIC_CALL_TRAMP(key)));	\
+	__static_call_update(key, func);				\
 })
 
 #define EXPORT_STATIC_CALL(key)						\


^ permalink raw reply related	[flat|nested] 120+ messages in thread

* [RFC PATCH 2/2] net: core: rather hacky PoC implementation of dynamic calls
  2018-12-12 17:47         ` [RFC/WIP PATCH 0/2] dynamic calls Edward Cree
  2018-12-12 17:50           ` [RFC PATCH 1/2] static_call: fix out-of-line static call implementation Edward Cree
@ 2018-12-12 17:52           ` Edward Cree
  1 sibling, 0 replies; 120+ messages in thread
From: Edward Cree @ 2018-12-12 17:52 UTC (permalink / raw)
  To: Nadav Amit, Josh Poimboeuf; +Cc: linux-kernel, x86, Paolo Abeni

Uses runtime instrumentation of callees from an indirect call site
 (deliver_skb, and also __netif_receive_skb_one_core()) to populate an
 indirect-call-wrapper branch tree.  Essentially we're doing indirect
 branch prediction in software because the hardware can't be trusted to
 get it right; this is sad.

It's also full of printk()s right now to display what it's doing for
 debugging purposes; obviously those wouldn't be quite the same in a
 finished version.

Signed-off-by: Edward Cree <ecree@solarflare.com>
---
 net/core/dev.c | 222 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--
 1 file changed, 217 insertions(+), 5 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index 04a6b7100aac..f69c110c34e3 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -145,6 +145,7 @@
 #include <linux/sctp.h>
 #include <net/udp_tunnel.h>
 #include <linux/net_namespace.h>
+#include <linux/static_call.h>
 
 #include "net-sysfs.h"
 
@@ -1935,14 +1936,223 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
 }
 EXPORT_SYMBOL_GPL(dev_forward_skb);
 
-static inline int deliver_skb(struct sk_buff *skb,
-			      struct packet_type *pt_prev,
-			      struct net_device *orig_dev)
+static void deliver_skb_update(struct work_struct *unused);
+
+static DECLARE_WORK(deliver_skb_update_work, deliver_skb_update);
+
+typedef int (*deliver_skb_func)(struct sk_buff *, struct net_device *, struct packet_type *, struct net_device *);
+
+struct deliver_skb_candidate {
+	deliver_skb_func func;
+	unsigned long hit_count;
+};
+
+static DEFINE_PER_CPU(struct deliver_skb_candidate[4], deliver_skb_candidates);
+
+static DEFINE_PER_CPU(unsigned long, deliver_skb_miss_count);
+
+/* Used to route around the dynamic version when we're changing it, as well as
+ * as a fallback if none of our static calls match.
+ */
+static int do_deliver_skb(struct sk_buff *skb,
+			  struct packet_type *pt_prev,
+			  struct net_device *orig_dev)
+{
+	struct deliver_skb_candidate *cands = *this_cpu_ptr(&deliver_skb_candidates);
+	deliver_skb_func func = pt_prev->func;
+	unsigned long total_count;
+	int i;
+
+	for (i = 0; i < 4; i++)
+		if (func == cands[i].func) {
+			cands[i].hit_count++;
+			break;
+		}
+	if (i == 4) /* no match */
+		for (i = 0; i < 4; i++)
+			if (!cands[i].func) {
+				cands[i].func = func;
+				cands[i].hit_count = 1;
+				break;
+			}
+	if (i == 4) /* no space */
+		(*this_cpu_ptr(&deliver_skb_miss_count))++;
+
+	total_count = *this_cpu_ptr(&deliver_skb_miss_count);
+	for (i = 0; i < 4; i++)
+		total_count += cands[i].hit_count;
+	if (total_count > 1000) /* Arbitrary threshold */
+		schedule_work(&deliver_skb_update_work);
+	return pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+}
+
+DEFINE_STATIC_CALL(dispatch_deliver_skb, do_deliver_skb);
+
+static int dummy_deliver_skb(struct sk_buff *skb, struct net_device *dev,
+			     struct packet_type *pt_prev,
+			     struct net_device *orig_dev)
+{
+	WARN_ON_ONCE(1); /* shouldn't ever actually get here */
+	return do_deliver_skb(skb, pt_prev, orig_dev);
+}
+
+DEFINE_STATIC_CALL(dynamic_deliver_skb_1, dummy_deliver_skb);
+DEFINE_STATIC_CALL(dynamic_deliver_skb_2, dummy_deliver_skb);
+
+static DEFINE_PER_CPU(unsigned long, dds1_hit_count);
+static DEFINE_PER_CPU(unsigned long, dds2_hit_count);
+
+static int dynamic_deliver_skb(struct sk_buff *skb,
+			       struct packet_type *pt_prev,
+			       struct net_device *orig_dev)
+{
+	deliver_skb_func func = pt_prev->func;
+
+	if (func == dynamic_deliver_skb_1.func) {
+		(*this_cpu_ptr(&dds1_hit_count))++;
+		return static_call(dynamic_deliver_skb_1, skb, skb->dev,
+				   pt_prev, orig_dev);
+	}
+	if (func == dynamic_deliver_skb_2.func) {
+		(*this_cpu_ptr(&dds2_hit_count))++;
+		return static_call(dynamic_deliver_skb_2, skb, skb->dev,
+				   pt_prev, orig_dev);
+	}
+	return do_deliver_skb(skb, pt_prev, orig_dev);
+}
+
+DEFINE_MUTEX(deliver_skb_update_lock);
+
+static void deliver_skb_add_cand(struct deliver_skb_candidate *top,
+				 size_t ncands,
+				 struct deliver_skb_candidate next)
+{
+	struct deliver_skb_candidate old;
+	int i;
+
+	for (i = 0; i < ncands; i++) {
+		if (next.hit_count > top[i].hit_count) {
+			/* Swap next with top[i], so that the old top[i] can
+			 * shunt along all lower scores
+			 */
+			old = top[i];
+			top[i] = next;
+			next = old;
+		}
+	}
+}
+
+static void deliver_skb_count_hits(struct deliver_skb_candidate *top,
+				   size_t ncands, struct static_call_key *key,
+				   unsigned long __percpu *hit_count)
+{
+	struct deliver_skb_candidate next;
+	int cpu;
+
+	next.func = key->func;
+	next.hit_count = 0;
+	for_each_online_cpu(cpu) {
+		next.hit_count += *per_cpu_ptr(hit_count, cpu);
+		*per_cpu_ptr(hit_count, cpu) = 0;
+	}
+
+	printk(KERN_ERR "hit_count for old %pf: %lu\n", next.func,
+	       next.hit_count);
+
+	deliver_skb_add_cand(top, ncands, next);
+}
+
+static void deliver_skb_update(struct work_struct *unused)
+{
+	struct deliver_skb_candidate top[4], next, *cands, *cands2;
+	int cpu, i, cpu2, j;
+
+	memset(top, 0, sizeof(top));
+
+	printk(KERN_ERR "deliver_skb_update called\n");
+	mutex_lock(&deliver_skb_update_lock);
+	printk(KERN_ERR "deliver_skb_update_lock acquired\n");
+	/* We don't stop the other CPUs adding to their counts while this is
+	 * going on; but it doesn't really matter because this is a heuristic
+	 * anyway so we don't care about perfect accuracy.
+	 */
+	/* First count up the hits on the existing static branches */
+	deliver_skb_count_hits(top, ARRAY_SIZE(top), &dynamic_deliver_skb_1,
+			       &dds1_hit_count);
+	deliver_skb_count_hits(top, ARRAY_SIZE(top), &dynamic_deliver_skb_2,
+			       &dds2_hit_count);
+	/* Next count up the callees seen in the fallback path */
+	for_each_online_cpu(cpu) {
+		cands = *per_cpu_ptr(&deliver_skb_candidates, cpu);
+		printk(KERN_ERR "miss_count for %d: %lu\n", cpu,
+		       *per_cpu_ptr(&deliver_skb_miss_count, cpu));
+		for (i = 0; i < 4; i++) {
+			next = cands[i];
+			if (next.func == NULL)
+				continue;
+			next.hit_count = 0;
+			for_each_online_cpu(cpu2) {
+				cands2 = *per_cpu_ptr(&deliver_skb_candidates,
+						      cpu2);
+				for (j = 0; j < 4; j++) {
+					if (cands2[j].func == next.func) {
+						next.hit_count += cands2[j].hit_count;
+						cands2[j].hit_count = 0;
+						cands2[j].func = NULL;
+						break;
+					}
+				}
+			}
+			printk(KERN_ERR "candidate %d/%d: %pf %lu\n", cpu, i,
+			       next.func, next.hit_count);
+			deliver_skb_add_cand(top, ARRAY_SIZE(top), next);
+		}
+	}
+	/* Record our results (for debugging) */
+	for (i = 0; i < ARRAY_SIZE(top); i++) {
+		if (i < 2) /* 2 == number of static calls in the branch tree */
+			printk(KERN_ERR "selected [%d] %pf, score %lu\n", i,
+			       top[i].func, top[i].hit_count);
+		else
+			printk(KERN_ERR "runnerup [%d] %pf, score %lu\n", i,
+			       top[i].func, top[i].hit_count);
+	}
+	/* It's possible that we could have picked up multiple pushes of the
+	 * workitem, so someone already collected most of the count.  In that
+	 * case, don't make a decision based on only a small number of calls.
+	 */
+	if (top[0].hit_count > 250) {
+		/* Divert callers away from the fast path */
+		static_call_update(dispatch_deliver_skb, do_deliver_skb);
+		printk(KERN_ERR "patched dds to %pf\n", dispatch_deliver_skb.func);
+		/* Wait for existing fast path callers to finish */
+		synchronize_rcu();
+		/* Patch the chosen callees into the fast path */
+		static_call_update(dynamic_deliver_skb_1, *top[0].func);
+		printk(KERN_ERR "patched dds1 to %pf\n", dynamic_deliver_skb_1.func);
+		static_call_update(dynamic_deliver_skb_2, *top[1].func);
+		printk(KERN_ERR "patched dds2 to %pf\n", dynamic_deliver_skb_2.func);
+		/* Ensure the new fast path is seen before we direct anyone
+		 * into it.  This probably isn't necessary (the binary-patching
+		 * framework probably takes care of it) but let's be paranoid.
+		 */
+		wmb();
+		/* Switch callers back onto the fast path */
+		static_call_update(dispatch_deliver_skb, dynamic_deliver_skb);
+		printk(KERN_ERR "patched dds to %pf\n", dispatch_deliver_skb.func);
+	}
+	mutex_unlock(&deliver_skb_update_lock);
+	printk(KERN_ERR "deliver_skb_update finished\n");
+}
+
+static noinline int deliver_skb(struct sk_buff *skb,
+				struct packet_type *pt_prev,
+				struct net_device *orig_dev)
 {
 	if (unlikely(skb_orphan_frags_rx(skb, GFP_ATOMIC)))
 		return -ENOMEM;
 	refcount_inc(&skb->users);
-	return pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+	return static_call(dispatch_deliver_skb, skb, pt_prev, orig_dev);
 }
 
 static inline void deliver_ptype_list_skb(struct sk_buff *skb,
@@ -4951,7 +5161,9 @@ static int __netif_receive_skb_one_core(struct sk_buff *skb, bool pfmemalloc)
 
 	ret = __netif_receive_skb_core(skb, pfmemalloc, &pt_prev);
 	if (pt_prev)
-		ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev);
+		/* ret = pt_prev->func(skb, skb->dev, pt_prev, orig_dev); */
+		/* but (hopefully) faster */
+		ret = static_call(dispatch_deliver_skb, skb, pt_prev, orig_dev);
 	return ret;
 }
 

^ permalink raw reply related	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-12 17:11       ` Edward Cree
  2018-12-12 17:47         ` [RFC/WIP PATCH 0/2] dynamic calls Edward Cree
@ 2018-12-12 18:14         ` Nadav Amit
  2018-12-12 18:33           ` Edward Cree
  1 sibling, 1 reply; 120+ messages in thread
From: Nadav Amit @ 2018-12-12 18:14 UTC (permalink / raw)
  To: Edward Cree; +Cc: Josh Poimboeuf, LKML, x86, Paolo Abeni

> On Dec 12, 2018, at 9:11 AM, Edward Cree <ecree@solarflare.com> wrote:
> 
> On 12/12/18 05:59, Nadav Amit wrote:
>> Thanks for cc’ing me. (I didn’t know about the other patch-sets.)
> Well in my case, that's because I haven't posted any yet.  (Will follow up
>  shortly with what I currently have, though it's not pretty.)
> 
> Looking at your patches, it seems you've got a much more developed learning
>  mechanism.  Mine on the other hand is brutally simple but runs continuously
>  (i.e. after we patch we immediately enter the next 'relearning' phase);
>  since it never does anything but prod a handful of percpu variables, this
>  shouldn't be too costly.
> 
> Also, you've got the macrology for making all indirect calls use this,
>  whereas at present I just have an open-coded instance on a single call site
>  (I went with deliver_skb in the networking stack).
> 
> So I think where we probably want to go from here is:
>  1) get Josh's static_calls in.  AIUI Linus seems to prefer the out-of-line
>     approach; I'd say ditch the inline version (at least for now).
>  2) build a relpolines patch series that uses
>    i) static_calls for the text-patching part
>   ii) as much of Nadav's macrology as is applicable
>  iii) either my or Nadav's learning mechanism; we can experiment with both,
>       bikeshed it incessantly etc.
> 
> Seem reasonable?

Mostly yes. I have a few reservations (and let’s call them optpolines from
now on, since Josh disliked the previous name).

First, I still have to address the issues that Josh raised before, and try
to use gcc plugin instead of (most) of the macros. Specifically, I need to
bring back (from my PoC code) the part that sets multiple targets.

Second, (2i) is not very intuitive for me. Using the out-of-line static
calls seems to me as less performant than the inline (potentially, I didn’t
check).

Anyhow, the use of out-of-line static calls seems to me as
counter-intuitive. I think (didn’t measure) that it may add more overhead
than it saves due to the additional call, ret, and so on - at least if
retpolines are not used. For multiple targets it may be useful in saving
some memory if the outline block is dynamically allocated (as I did in my
yet unpublished code). But that’s not how it’s done in Josh’s code.

If we talk about inline implementation there is a different problem that
prevents me of using Josh’s static-calls as-is. I tried to avoid reading to
compared target from memory and therefore used an immediate. This should
prevent data cache misses and even when the data is available is faster by
one cycle. But it requires the patching of both the “cmp %target-reg, imm”
and “call rel-target” to be patched “atomically”. So the static-calls
mechanism wouldn’t be sufficient.

Based on Josh’s previous feedback, I thought of improving the learning using
some hysteresis. Anyhow, note that there are quite a few cases in which you
wouldn’t want optpolines. The question is whether in general it would be an
opt-in or opt-out mechanism.

Let me know what you think.

BTW: When it comes to deliver_skb, you have packet_type as an identifier.
You can use it directly or through an indirection table to figure the
target. Here’s a chunk of assembly magic that I used in a similar case:

.macro _call_table val:req bit:req max:req val1:req bit1:req
call_table_\val\()_\bit\():
        test $(1 << \bit), %al
.if \val1 + (1 << \bit1) >= \max
        jnz syscall_relpoline_\val1
        jmp syscall_relpoline_\val
.else
        jnz call_table_\val1\()_\bit1

        # fall-through to no carry, val unchange, going to next bit
        call_table \val,\bit1,\max
        call_table \val1,\bit1,\max
.endif
.endm

.macro call_table val:req bit:req max:req
.altmacro
        _call_table \val,\bit,\max,%(\val + (1 << \bit)),%(\bit + 1)
.noaltmacro
.endm

ENTRY(direct_syscall)
        mov %esi, %eax
        call_table val=0 bit=0 max=16
ENDPROC(direct_syscall)

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64
  2018-11-29 23:04                                                   ` Linus Torvalds
  2018-11-30 16:27                                                     ` Josh Poimboeuf
@ 2018-12-12 18:29                                                     ` Josh Poimboeuf
  1 sibling, 0 replies; 120+ messages in thread
From: Josh Poimboeuf @ 2018-12-12 18:29 UTC (permalink / raw)
  To: Linus Torvalds
  Cc: Andrew Lutomirski, Steven Rostedt, Peter Zijlstra,
	the arch/x86 maintainers, Linux List Kernel Mailing,
	Ard Biesheuvel, Ingo Molnar, Thomas Gleixner, mhiramat, jbaron,
	Jiri Kosina, David.Laight, bp, julia, jeyu, Peter Anvin

On Thu, Nov 29, 2018 at 03:04:20PM -0800, Linus Torvalds wrote:
> On Thu, Nov 29, 2018 at 12:25 PM Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > On Thu, Nov 29, 2018 at 11:27:00AM -0800, Andy Lutomirski wrote:
> > >
> > > I propose a different solution:
> > >
> > > As in this patch set, we have a direct and an indirect version.  The
> > > indirect version remains exactly the same as in this patch set.  The
> > > direct version just only does the patching when all seems well: the
> > > call instruction needs to be 0xe8, and we only do it when the thing
> > > doesn't cross a cache line.  Does that work?  In the rare case where
> > > the compiler generates something other than 0xe8 or crosses a cache
> > > line, then the thing just remains as a call to the out of line jmp
> > > trampoline.  Does that seem reasonable?  It's a very minor change to
> > > the patch set.
> >
> > Maybe that would be ok.  If my math is right, we would use the
> > out-of-line version almost 5% of the time due to cache misalignment of
> > the address.
> 
> Note that I don't think cache-line alignment is necessarily sufficient.
> 
> The I$ fetch from the cacheline can happen in smaller chunks, because
> the bus between the I$ and the instruction decode isn't a full
> cacheline (well, it is _now_ in modern big cores, but it hasn't always
> been).
> 
> So even if the cacheline is updated atomically, I could imagine seeing
> a partial fetch from the I$ (old values) and then a second partial
> fetch (new values).
> 
> It would be interesting to know what the exact fetch rules are.

So I fixed my test case to do 32-bit writes, and now the results are
making a lot more sense.  Now I only get crashes when writing across
cache lines.  So maybe we should just go with Andy's suggestion above.

It would be great if some CPU people could confirm that it's safe (for
x86-64 only), since it's not in the SDM.  Who can help answer that?

-- 
Josh

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-12 18:14         ` [PATCH v2 0/4] Static calls Nadav Amit
@ 2018-12-12 18:33           ` Edward Cree
  2018-12-12 21:15             ` Nadav Amit
  0 siblings, 1 reply; 120+ messages in thread
From: Edward Cree @ 2018-12-12 18:33 UTC (permalink / raw)
  To: Nadav Amit; +Cc: Josh Poimboeuf, LKML, x86, Paolo Abeni

On 12/12/18 18:14, Nadav Amit wrote:
> Second, (2i) is not very intuitive for me. Using the out-of-line static
> calls seems to me as less performant than the inline (potentially, I didn’t
> check).
>
> Anyhow, the use of out-of-line static calls seems to me as
> counter-intuitive. I think (didn’t measure) that it may add more overhead
> than it saves due to the additional call, ret, and so on
AIUI the outline version uses a tail-call (i.e. jmpq *target) rather than an
 additional call and ret.  So I wouldn't expect it to be too expensive.
More to the point, it seems like it's easier to get right than the inline
 version, and if we get the inline version working later we can introduce it
 without any API change, much as Josh's existing patches have both versions
 behind a Kconfig switch.

> I tried to avoid reading to
> compared target from memory and therefore used an immediate. This should
> prevent data cache misses and even when the data is available is faster by
> one cycle. But it requires the patching of both the “cmp %target-reg, imm”
> and “call rel-target” to be patched “atomically”. So the static-calls
> mechanism wouldn’t be sufficient.
The approach I took to deal with that (since though I'm doing a read from
 memory, it's key->func in .data rather than the jmp immediate in .text) was
 to have another static_call (though a plain static_key could also be used)
 to 'skip' the fast-path while it's actually being patched.  Then, since all
 my callers were under the rcu_read_lock, I just needed to synchronize_rcu()
 after switching off the fast-path to make sure no threads were still in it.
I'm not sure how that would be generalised to all cases, though; we don't
 want to force every indirect call to take the rcu_read_lock as that means
 no callee can ever synchronize_rcu().  I guess we could have our own
 separate RCU read lock just for indirect call patching?  (What does kgraft
 do?)

> Based on Josh’s previous feedback, I thought of improving the learning using
> some hysteresis. Anyhow, note that there are quite a few cases in which you
> wouldn’t want optpolines. The question is whether in general it would be an
> opt-in or opt-out mechanism.
I was working on the assumption that it would be opt-in, wrapping a macro
 around indirect calls that are known to have a fairly small number of hot
 targets.  There are plenty of indirect calls in the kernel that are only
 called once in a blue moon, e.g. in control-plane operations like ethtool;
 we don't really need to bulk up .text with trampolines for all of them.

-Ed

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-12 18:33           ` Edward Cree
@ 2018-12-12 21:15             ` Nadav Amit
  2018-12-12 21:36               ` Edward Cree
  0 siblings, 1 reply; 120+ messages in thread
From: Nadav Amit @ 2018-12-12 21:15 UTC (permalink / raw)
  To: Edward Cree; +Cc: Josh Poimboeuf, LKML, x86, Paolo Abeni

> On Dec 12, 2018, at 10:33 AM, Edward Cree <ecree@solarflare.com> wrote:
> 
> On 12/12/18 18:14, Nadav Amit wrote:
>> Second, (2i) is not very intuitive for me. Using the out-of-line static
>> calls seems to me as less performant than the inline (potentially, I didn’t
>> check).
>> 
>> Anyhow, the use of out-of-line static calls seems to me as
>> counter-intuitive. I think (didn’t measure) that it may add more overhead
>> than it saves due to the additional call, ret, and so on
> AIUI the outline version uses a tail-call (i.e. jmpq *target) rather than an
>  additional call and ret.  So I wouldn't expect it to be too expensive.
> More to the point, it seems like it's easier to get right than the inline
>  version, and if we get the inline version working later we can introduce it
>  without any API change, much as Josh's existing patches have both versions
>  behind a Kconfig switch.

I see. For my outlined blocks I used the opposite approach - a call followed
by jmp (instead of jmp followed by call that Josh did). Does the stack look
correct when you first do the jmp? It seems to me that you will not see the
calling function on the stack in this case. Can it have an effect on
live-patching, debugging?

>> I tried to avoid reading to
>> compared target from memory and therefore used an immediate. This should
>> prevent data cache misses and even when the data is available is faster by
>> one cycle. But it requires the patching of both the “cmp %target-reg, imm”
>> and “call rel-target” to be patched “atomically”. So the static-calls
>> mechanism wouldn’t be sufficient.
> The approach I took to deal with that (since though I'm doing a read from
>  memory, it's key->func in .data rather than the jmp immediate in .text) was
>  to have another static_call (though a plain static_key could also be used)
>  to 'skip' the fast-path while it's actually being patched.  Then, since all
>  my callers were under the rcu_read_lock, I just needed to synchronize_rcu()
>  after switching off the fast-path to make sure no threads were still in it.
> I'm not sure how that would be generalised to all cases, though; we don't
>  want to force every indirect call to take the rcu_read_lock as that means
>  no callee can ever synchronize_rcu().  I guess we could have our own
>  separate RCU read lock just for indirect call patching?  (What does kgraft
>  do?)

I used a similar approach to a certain extent. (I’m going to describe the
implementation following the discussion with Andy Lutomirski): We use a
“restartable section” that if we need to be preempted in this block of code,
we restart the entire section. Then, we use synchronize_rcu() like you do
after patching.

>> Based on Josh’s previous feedback, I thought of improving the learning using
>> some hysteresis. Anyhow, note that there are quite a few cases in which you
>> wouldn’t want optpolines. The question is whether in general it would be an
>> opt-in or opt-out mechanism.
> I was working on the assumption that it would be opt-in, wrapping a macro
>  around indirect calls that are known to have a fairly small number of hot
>  targets.  There are plenty of indirect calls in the kernel that are only
>  called once in a blue moon, e.g. in control-plane operations like ethtool;
>  we don't really need to bulk up .text with trampolines for all of them.

On the other hand, I’m not sure the static_call interface is so intuitive.
And extending it into “dynamic_call” might be even worse. As I initially
used an opt-in approach, I can tell you that it was very exhausting.


^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-12 21:15             ` Nadav Amit
@ 2018-12-12 21:36               ` Edward Cree
  2018-12-12 21:45                 ` Nadav Amit
  0 siblings, 1 reply; 120+ messages in thread
From: Edward Cree @ 2018-12-12 21:36 UTC (permalink / raw)
  To: Nadav Amit; +Cc: Josh Poimboeuf, LKML, x86, Paolo Abeni

On 12/12/18 21:15, Nadav Amit wrote:
>> On Dec 12, 2018, at 10:33 AM, Edward Cree <ecree@solarflare.com> wrote:
>>
>> AIUI the outline version uses a tail-call (i.e. jmpq *target) rather than an
>>  additional call and ret.  So I wouldn't expect it to be too expensive.
>> More to the point, it seems like it's easier to get right than the inline
>>  version, and if we get the inline version working later we can introduce it
>>  without any API change, much as Josh's existing patches have both versions
>>  behind a Kconfig switch.
> I see. For my outlined blocks I used the opposite approach - a call followed
> by jmp
That's what Josh did too.  I.e. caller calls the trampoline, which jmps to the
 callee; later it rets, taking it back to the caller.  Perhaps I wasn't clear.
The point is that there's still only one call and one ret.

>> I was working on the assumption that it would be opt-in, wrapping a macro
>>  around indirect calls that are known to have a fairly small number of hot
>>  targets.  There are plenty of indirect calls in the kernel that are only
>>  called once in a blue moon, e.g. in control-plane operations like ethtool;
>>  we don't really need to bulk up .text with trampolines for all of them.
> On the other hand, I’m not sure the static_call interface is so intuitive.
> And extending it into “dynamic_call” might be even worse. As I initially
> used an opt-in approach, I can tell you that it was very exhausting.
Well, if it's done with a gcc plugin after all, then it wouldn't be too hard
 to make it opt-out.
One advantage of the explicit opt-in dynamic_call, though, which can be seen
 in my patch is that multiple call sites can share the same learning-state,
 if they're expected to call the same set of functions.  An opt-out approach
 would automatically give each indirect call statement its own individual BTB.
Either way, I think the question is orthogonal to what the trampolines
 themselves look like (and even to the inline vs outline question).

-Ed

^ permalink raw reply	[flat|nested] 120+ messages in thread

* Re: [PATCH v2 0/4] Static calls
  2018-12-12 21:36               ` Edward Cree
@ 2018-12-12 21:45                 ` Nadav Amit
  0 siblings, 0 replies; 120+ messages in thread
From: Nadav Amit @ 2018-12-12 21:45 UTC (permalink / raw)
  To: Edward Cree; +Cc: Josh Poimboeuf, LKML, x86, Paolo Abeni

> On Dec 12, 2018, at 1:36 PM, Edward Cree <ecree@solarflare.com> wrote:
> 
> On 12/12/18 21:15, Nadav Amit wrote:
>>> On Dec 12, 2018, at 10:33 AM, Edward Cree <ecree@solarflare.com> wrote:
>>> 
>>> AIUI the outline version uses a tail-call (i.e. jmpq *target) rather than an
>>> additional call and ret.  So I wouldn't expect it to be too expensive.
>>> More to the point, it seems like it's easier to get right than the inline
>>> version, and if we get the inline version working later we can introduce it
>>> without any API change, much as Josh's existing patches have both versions
>>> behind a Kconfig switch.
>> I see. For my outlined blocks I used the opposite approach - a call followed
>> by jmp
> That's what Josh did too.  I.e. caller calls the trampoline, which jmps to the
>  callee; later it rets, taking it back to the caller.  Perhaps I wasn't clear.
> The point is that there's still only one call and one ret.

Sorry for the misunderstanding.

> 
>>> I was working on the assumption that it would be opt-in, wrapping a macro
>>> around indirect calls that are known to have a fairly small number of hot
>>> targets.  There are plenty of indirect calls in the kernel that are only
>>> called once in a blue moon, e.g. in control-plane operations like ethtool;
>>> we don't really need to bulk up .text with trampolines for all of them.
>> On the other hand, I’m not sure the static_call interface is so intuitive.
>> And extending it into “dynamic_call” might be even worse. As I initially
>> used an opt-in approach, I can tell you that it was very exhausting.
> Well, if it's done with a gcc plugin after all, then it wouldn't be too hard
>  to make it opt-out.
> One advantage of the explicit opt-in dynamic_call, though, which can be seen
>  in my patch is that multiple call sites can share the same learning-state,
>  if they're expected to call the same set of functions.  An opt-out approach
>  would automatically give each indirect call statement its own individual BTB.
> Either way, I think the question is orthogonal to what the trampolines
>  themselves look like (and even to the inline vs outline question).

Not entirely. If the mechanism is opt-out and outlined, and especially if it
also supports multiple targets, you may not want to allocate all the memory
for them during build-time, and instead use module memory to allocate them
dynamically (that’s what we did).

^ permalink raw reply	[flat|nested] 120+ messages in thread

end of thread, other threads:[~2018-12-12 21:46 UTC | newest]

Thread overview: 120+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-11-26 13:54 [PATCH v2 0/4] Static calls Josh Poimboeuf
2018-11-26 13:54 ` [PATCH v2 1/4] compiler.h: Make __ADDRESSABLE() symbol truly unique Josh Poimboeuf
2018-11-27  8:49   ` Ard Biesheuvel
2018-11-26 13:54 ` [PATCH v2 2/4] static_call: Add static call infrastructure Josh Poimboeuf
2018-11-26 13:54 ` [PATCH v2 3/4] x86/static_call: Add out-of-line static call implementation Josh Poimboeuf
2018-11-26 15:43   ` Peter Zijlstra
2018-11-26 16:19     ` Steven Rostedt
2018-11-26 13:55 ` [PATCH v2 4/4] x86/static_call: Add inline static call implementation for x86-64 Josh Poimboeuf
2018-11-26 16:02   ` Peter Zijlstra
2018-11-26 17:10     ` Josh Poimboeuf
2018-11-26 17:56       ` Josh Poimboeuf
2018-11-26 20:00         ` Peter Zijlstra
2018-11-26 20:08         ` Peter Zijlstra
2018-11-26 21:26           ` Josh Poimboeuf
2018-11-27  8:43             ` Peter Zijlstra
2018-11-27  8:50               ` Peter Zijlstra
2018-11-29  6:05               ` Andy Lutomirski
2018-11-29  9:42                 ` Peter Zijlstra
2018-11-29 13:11                   ` Josh Poimboeuf
2018-11-29 13:37                   ` Andy Lutomirski
2018-11-29 14:38                     ` Peter Zijlstra
2018-11-29 14:42                       ` Jiri Kosina
2018-11-29 16:33                       ` Josh Poimboeuf
2018-11-29 16:49                         ` Peter Zijlstra
2018-11-29 16:59                           ` Andy Lutomirski
2018-11-29 17:10                             ` Josh Poimboeuf
2018-11-29 22:01                               ` Peter Zijlstra
2018-11-29 22:14                                 ` Josh Poimboeuf
2018-11-29 22:22                                   ` Peter Zijlstra
2018-11-29 22:25                                     ` Andy Lutomirski
2018-11-29 22:30                                       ` Josh Poimboeuf
2018-11-29 17:15                             ` Peter Zijlstra
2018-11-29 17:20                               ` Steven Rostedt
2018-11-29 17:21                                 ` Steven Rostedt
2018-11-29 17:41                                   ` Andy Lutomirski
2018-11-29 17:45                                     ` Josh Poimboeuf
2018-11-29 17:52                                       ` Andy Lutomirski
2018-11-29 17:49                                     ` Steven Rostedt
2018-11-29 18:37                               ` Josh Poimboeuf
2018-11-29 16:50                         ` Linus Torvalds
2018-11-29 16:55                           ` Steven Rostedt
2018-11-29 17:02                           ` Andy Lutomirski
2018-11-29 17:07                             ` Peter Zijlstra
2018-11-29 17:31                               ` Andy Lutomirski
2018-11-29 17:35                                 ` Jiri Kosina
2018-11-29 17:13                             ` Steven Rostedt
2018-11-29 17:35                               ` Linus Torvalds
2018-11-29 17:44                                 ` Steven Rostedt
2018-11-29 17:50                                   ` Linus Torvalds
2018-11-29 17:54                                     ` Linus Torvalds
2018-11-29 17:58                                     ` Steven Rostedt
2018-11-29 18:23                                       ` Linus Torvalds
2018-11-29 18:47                                         ` Steven Rostedt
2018-11-29 18:58                                           ` Linus Torvalds
2018-11-29 19:08                                             ` Linus Torvalds
2018-11-29 19:11                                               ` Linus Torvalds
2018-12-10 23:58                                                 ` Pavel Machek
2018-12-11  1:43                                                   ` Linus Torvalds
2018-11-29 19:12                                               ` Steven Rostedt
2018-11-29 19:27                                               ` Andy Lutomirski
2018-11-29 20:24                                                 ` Josh Poimboeuf
2018-11-29 22:17                                                   ` Josh Poimboeuf
2018-11-29 23:04                                                   ` Linus Torvalds
2018-11-30 16:27                                                     ` Josh Poimboeuf
2018-12-11  9:41                                                       ` David Laight
2018-12-11 17:19                                                         ` Josh Poimboeuf
2018-12-12 18:29                                                     ` Josh Poimboeuf
2018-11-30 16:42                                                   ` Andy Lutomirski
2018-11-30 18:39                                                     ` Josh Poimboeuf
2018-11-30 19:45                                                       ` Linus Torvalds
2018-11-30 20:18                                                         ` Andy Lutomirski
2018-11-30 20:28                                                           ` Steven Rostedt
2018-11-30 20:59                                                             ` Andy Lutomirski
2018-11-30 21:01                                                               ` Steven Rostedt
2018-11-30 21:13                                                               ` Jiri Kosina
2018-11-30 21:10                                                           ` Josh Poimboeuf
2018-11-29 19:16                                             ` Steven Rostedt
2018-11-29 19:22                                               ` Josh Poimboeuf
2018-11-29 19:27                                                 ` Steven Rostedt
2018-11-30 22:16                                                 ` Rasmus Villemoes
2018-11-30 22:24                                                   ` Josh Poimboeuf
2018-11-29 19:24                                               ` Linus Torvalds
2018-11-29 19:28                                                 ` Andy Lutomirski
2018-11-29 19:31                                                 ` Steven Rostedt
2018-11-29 20:12                                             ` Josh Poimboeuf
2018-11-29 18:00                                     ` Andy Lutomirski
2018-11-29 18:42                                       ` Linus Torvalds
2018-11-29 18:55                                       ` Steven Rostedt
2018-11-29 17:29                             ` Linus Torvalds
2018-11-29 17:35                               ` Andy Lutomirski
2018-11-26 18:28       ` Andy Lutomirski
2018-11-26 20:14         ` Josh Poimboeuf
2018-11-27  8:46           ` Peter Zijlstra
2018-11-26 16:08   ` Peter Zijlstra
2018-11-26 16:11     ` Ard Biesheuvel
2018-11-26 16:33       ` Andy Lutomirski
2018-11-26 16:39       ` Peter Zijlstra
2018-11-26 16:44         ` Josh Poimboeuf
2018-11-26 14:01 ` [PATCH v2 0/4] Static calls Josh Poimboeuf
2018-11-26 20:54 ` Steven Rostedt
2018-11-26 22:24   ` Josh Poimboeuf
2018-11-26 22:53     ` Steven Rostedt
2018-12-04 23:08 ` Steven Rostedt
2018-12-04 23:41   ` Andy Lutomirski
2018-12-05 15:04     ` Josh Poimboeuf
2018-12-05 23:36       ` Andy Lutomirski
2018-12-07 16:06 ` Edward Cree
2018-12-07 16:49   ` Edward Cree
2018-12-11 18:05   ` Josh Poimboeuf
2018-12-12  5:59     ` Nadav Amit
2018-12-12 17:11       ` Edward Cree
2018-12-12 17:47         ` [RFC/WIP PATCH 0/2] dynamic calls Edward Cree
2018-12-12 17:50           ` [RFC PATCH 1/2] static_call: fix out-of-line static call implementation Edward Cree
2018-12-12 17:52           ` [RFC PATCH 2/2] net: core: rather hacky PoC implementation of dynamic calls Edward Cree
2018-12-12 18:14         ` [PATCH v2 0/4] Static calls Nadav Amit
2018-12-12 18:33           ` Edward Cree
2018-12-12 21:15             ` Nadav Amit
2018-12-12 21:36               ` Edward Cree
2018-12-12 21:45                 ` Nadav Amit
2018-12-10 23:57 ` Pavel Machek

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.