Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Commit 1a4a2bc4 authored by Linus Torvalds's avatar Linus Torvalds
Browse files

Merge branch 'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

Pull low-level x86 updates from Ingo Molnar:
 "In this cycle this topic tree has become one of those 'super topics'
  that accumulated a lot of changes:

   - Add CONFIG_VMAP_STACK=y support to the core kernel and enable it on
     x86 - preceded by an array of changes. v4.8 saw preparatory changes
     in this area already - this is the rest of the work. Includes the
     thread stack caching performance optimization. (Andy Lutomirski)

   - switch_to() cleanups and all around enhancements. (Brian Gerst)

   - A large number of dumpstack infrastructure enhancements and an
     unwinder abstraction. The secret long term plan is safe(r) live
     patching plus maybe another attempt at debuginfo based unwinding -
     but all these current bits are standalone enhancements in a frame
     pointer based debug environment as well. (Josh Poimboeuf)

   - More __ro_after_init and const annotations. (Kees Cook)

   - Enable KASLR for the vmemmap memory region. (Thomas Garnier)"

[ The virtually mapped stack changes are pretty fundamental, and not
  x86-specific per se, even if they are only used on x86 right now. ]

* 'x86-asm-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (70 commits)
  x86/asm: Get rid of __read_cr4_safe()
  thread_info: Use unsigned long for flags
  x86/alternatives: Add stack frame dependency to alternative_call_2()
  x86/dumpstack: Fix show_stack() task pointer regression
  x86/dumpstack: Remove dump_trace() and related callbacks
  x86/dumpstack: Convert show_trace_log_lvl() to use the new unwinder
  oprofile/x86: Convert x86_backtrace() to use the new unwinder
  x86/stacktrace: Convert save_stack_trace_*() to use the new unwinder
  perf/x86: Convert perf_callchain_kernel() to use the new unwinder
  x86/unwind: Add new unwind interface and implementations
  x86/dumpstack: Remove NULL task pointer convention
  fork: Optimize task creation by caching two thread stacks per CPU if CONFIG_VMAP_STACK=y
  sched/core: Free the stack early if CONFIG_THREAD_INFO_IN_TASK
  lib/syscall: Pin the task stack in collect_syscall()
  x86/process: Pin the target stack in get_wchan()
  x86/dumpstack: Pin the target stack when dumping it
  kthread: Pin the stack via try_get_task_stack()/put_task_stack() in to_live_kthread() function
  sched/core: Add try_get_task_stack() and put_task_stack()
  x86/entry/64: Fix a minor comment rebase error
  iommu/amd: Don't put completion-wait semaphore on stack
  ...
parents 110a9e42 1ef55be1
Loading
Loading
Loading
Loading
+11 −0
Original line number Diff line number Diff line
@@ -203,6 +203,17 @@ along to ftrace_push_return_trace() instead of a stub value of 0.

Similarly, when you call ftrace_return_to_handler(), pass it the frame pointer.

HAVE_FUNCTION_GRAPH_RET_ADDR_PTR
--------------------------------

An arch may pass in a pointer to the return address on the stack.  This
prevents potential stack unwinding issues where the unwinder gets out of
sync with ret_stack and the wrong addresses are reported by
ftrace_graph_ret_addr().

Adding support for it is easy: just define the macro in asm/ftrace.h and
pass the return address pointer as the 'retp' argument to
ftrace_push_return_trace().

HAVE_FTRACE_NMI_ENTER
---------------------
+34 −0
Original line number Diff line number Diff line
@@ -696,4 +696,38 @@ config ARCH_NO_COHERENT_DMA_MMAP
config CPU_NO_EFFICIENT_FFS
	def_bool n

config HAVE_ARCH_VMAP_STACK
	def_bool n
	help
	  An arch should select this symbol if it can support kernel stacks
	  in vmalloc space.  This means:

	  - vmalloc space must be large enough to hold many kernel stacks.
	    This may rule out many 32-bit architectures.

	  - Stacks in vmalloc space need to work reliably.  For example, if
	    vmap page tables are created on demand, either this mechanism
	    needs to work while the stack points to a virtual address with
	    unpopulated page tables or arch code (switch_to() and switch_mm(),
	    most likely) needs to ensure that the stack's page table entries
	    are populated before running on a possibly unpopulated stack.

	  - If the stack overflows into a guard page, something reasonable
	    should happen.  The definition of "reasonable" is flexible, but
	    instantly rebooting without logging anything would be unfriendly.

config VMAP_STACK
	default y
	bool "Use a virtually-mapped stack"
	depends on HAVE_ARCH_VMAP_STACK && !KASAN
	---help---
	  Enable this if you want the use virtually-mapped kernel stacks
	  with guard pages.  This causes kernel stack overflows to be
	  caught immediately rather than causing difficult-to-diagnose
	  corruption.

	  This is presently incompatible with KASAN because KASAN expects
	  the stack to map directly to the KASAN shadow map using a formula
	  that is incorrect if the stack is in vmalloc space.

source "kernel/gcov/Kconfig"
+1 −1
Original line number Diff line number Diff line
@@ -218,7 +218,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr,
	}

	err = ftrace_push_return_trace(old, self_addr, &trace.depth,
				       frame_pointer);
				       frame_pointer, NULL);
	if (err == -EBUSY) {
		*parent = old;
		return;
+1 −1
Original line number Diff line number Diff line
@@ -219,7 +219,7 @@ ENDPROC(ftrace_graph_caller)
 *
 * Run ftrace_return_to_handler() before going back to parent.
 * @fp is checked against the value passed by ftrace_graph_caller()
 * only when CONFIG_HAVE_FUNCTION_GRAPH_FP_TEST is enabled.
 * only when HAVE_FUNCTION_GRAPH_FP_TEST is enabled.
 */
ENTRY(return_to_handler)
	save_return_regs
+1 −1
Original line number Diff line number Diff line
@@ -138,7 +138,7 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr,
		return;

	err = ftrace_push_return_trace(old, self_addr, &trace.depth,
				       frame_pointer);
				       frame_pointer, NULL);
	if (err == -EBUSY)
		return;
	else
Loading