1Kernel stacks on x86-64 bit
2---------------------------
3
4Most of the text from Keith Owens, hacked by AK
5
6x86_64 page size (PAGE_SIZE) is 4K.
7
8Like all other architectures, x86_64 has a kernel stack for every
9active thread.  These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big.
10These stacks contain useful data as long as a thread is alive or a
11zombie. While the thread is in user space the kernel stack is empty
12except for the thread_info structure at the bottom.
13
14In addition to the per thread stacks, there are specialized stacks
15associated with each CPU.  These stacks are only used while the kernel
16is in control on that CPU; when a CPU returns to user space the
17specialized stacks contain no useful data.  The main CPU stacks are:
18
19* Interrupt stack.  IRQ_STACK_SIZE
20
21  Used for external hardware interrupts.  If this is the first external
22  hardware interrupt (i.e. not a nested hardware interrupt) then the
23  kernel switches from the current task to the interrupt stack.  Like
24  the split thread and interrupt stacks on i386, this gives more room
25  for kernel interrupt processing without having to increase the size
26  of every per thread stack.
27
28  The interrupt stack is also used when processing a softirq.
29
30Switching to the kernel interrupt stack is done by software based on a
31per CPU interrupt nest counter. This is needed because x86-64 "IST"
32hardware stacks cannot nest without races.
33
34x86_64 also has a feature which is not available on i386, the ability
35to automatically switch to a new stack for designated events such as
36double fault or NMI, which makes it easier to handle these unusual
37events on x86_64.  This feature is called the Interrupt Stack Table
38(IST).  There can be up to 7 IST entries per CPU. The IST code is an
39index into the Task State Segment (TSS). The IST entries in the TSS
40point to dedicated stacks; each stack can be a different size.
41
42An IST is selected by a non-zero value in the IST field of an
43interrupt-gate descriptor.  When an interrupt occurs and the hardware
44loads such a descriptor, the hardware automatically sets the new stack
45pointer based on the IST value, then invokes the interrupt handler.  If
46the interrupt came from user mode, then the interrupt handler prologue
47will switch back to the per-thread stack.  If software wants to allow
48nested IST interrupts then the handler must adjust the IST values on
49entry to and exit from the interrupt handler.  (This is occasionally
50done, e.g. for debug exceptions.)
51
52Events with different IST codes (i.e. with different stacks) can be
53nested.  For example, a debug interrupt can safely be interrupted by an
54NMI.  arch/x86_64/kernel/entry.S::paranoidentry adjusts the stack
55pointers on entry to and exit from all IST events, in theory allowing
56IST events with the same code to be nested.  However in most cases, the
57stack size allocated to an IST assumes no nesting for the same code.
58If that assumption is ever broken then the stacks will become corrupt.
59
60The currently assigned IST stacks are :-
61
62* DOUBLEFAULT_STACK.  EXCEPTION_STKSZ (PAGE_SIZE).
63
64  Used for interrupt 8 - Double Fault Exception (#DF).
65
66  Invoked when handling one exception causes another exception. Happens
67  when the kernel is very confused (e.g. kernel stack pointer corrupt).
68  Using a separate stack allows the kernel to recover from it well enough
69  in many cases to still output an oops.
70
71* NMI_STACK.  EXCEPTION_STKSZ (PAGE_SIZE).
72
73  Used for non-maskable interrupts (NMI).
74
75  NMI can be delivered at any time, including when the kernel is in the
76  middle of switching stacks.  Using IST for NMI events avoids making
77  assumptions about the previous state of the kernel stack.
78
79* DEBUG_STACK.  DEBUG_STKSZ
80
81  Used for hardware debug interrupts (interrupt 1) and for software
82  debug interrupts (INT3).
83
84  When debugging a kernel, debug interrupts (both hardware and
85  software) can occur at any time.  Using IST for these interrupts
86  avoids making assumptions about the previous state of the kernel
87  stack.
88
89* MCE_STACK.  EXCEPTION_STKSZ (PAGE_SIZE).
90
91  Used for interrupt 18 - Machine Check Exception (#MC).
92
93  MCE can be delivered at any time, including when the kernel is in the
94  middle of switching stacks.  Using IST for MCE events avoids making
95  assumptions about the previous state of the kernel stack.
96
97For more details see the Intel IA32 or AMD AMD64 architecture manuals.
98
99
100Printing backtraces on x86
101--------------------------
102
103The question about the '?' preceding function names in an x86 stacktrace
104keeps popping up, here's an indepth explanation. It helps if the reader
105stares at print_context_stack() and the whole machinery in and around
106arch/x86/kernel/dumpstack.c.
107
108Adapted from Ingo's mail, Message-ID: <20150521101614.GA10889@gmail.com>:
109
110We always scan the full kernel stack for return addresses stored on
111the kernel stack(s) [*], from stack top to stack bottom, and print out
112anything that 'looks like' a kernel text address.
113
114If it fits into the frame pointer chain, we print it without a question
115mark, knowing that it's part of the real backtrace.
116
117If the address does not fit into our expected frame pointer chain we
118still print it, but we print a '?'. It can mean two things:
119
120 - either the address is not part of the call chain: it's just stale
121   values on the kernel stack, from earlier function calls. This is
122   the common case.
123
124 - or it is part of the call chain, but the frame pointer was not set
125   up properly within the function, so we don't recognize it.
126
127This way we will always print out the real call chain (plus a few more
128entries), regardless of whether the frame pointer was set up correctly
129or not - but in most cases we'll get the call chain right as well. The
130entries printed are strictly in stack order, so you can deduce more
131information from that as well.
132
133The most important property of this method is that we _never_ lose
134information: we always strive to print _all_ addresses on the stack(s)
135that look like kernel text addresses, so if debug information is wrong,
136we still print out the real call chain as well - just with more question
137marks than ideal.
138
139[*] For things like IRQ and IST stacks, we also scan those stacks, in
140    the right order, and try to cross from one stack into another
141    reconstructing the call chain. This works most of the time.
142