blob: 9a0aa4d3a866938170c1b652577c9ed9d69aab29 [file] [log] [blame]
Borislav Petkovd724a9a2015-05-26 10:28:19 +02001Kernel stacks on x86-64 bit
2---------------------------
3
Andi Kleen352f7ba2006-09-26 10:52:31 +02004Most 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
Randy Dunlap57d30772007-02-13 13:26:23 +010015associated 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:
Andi Kleen352f7ba2006-09-26 10:52:31 +020018
Alexander Kuleshov0fe09652015-08-21 15:19:06 +060019* Interrupt stack. IRQ_STACK_SIZE
Andi Kleen352f7ba2006-09-26 10:52:31 +020020
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
Christoph Hellwig79748912010-06-28 14:15:54 +020024 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.
Andi Kleen352f7ba2006-09-26 10:52:31 +020027
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
Randy Dunlap57d30772007-02-13 13:26:23 +010038(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.
Andi Kleen352f7ba2006-09-26 10:52:31 +020041
Randy Dunlap57d30772007-02-13 13:26:23 +010042An IST is selected by a non-zero value in the IST field of an
Andi Kleen352f7ba2006-09-26 10:52:31 +020043interrupt-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
Andy Lutomirski48e08d02014-11-11 12:49:41 -080046the 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.)
Andi Kleen352f7ba2006-09-26 10:52:31 +020051
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
Andi Kleen352f7ba2006-09-26 10:52:31 +020062* DOUBLEFAULT_STACK. EXCEPTION_STKSZ (PAGE_SIZE).
63
64 Used for interrupt 8 - Double Fault Exception (#DF).
65
Randy Dunlap57d30772007-02-13 13:26:23 +010066 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.
Andi Kleen352f7ba2006-09-26 10:52:31 +020070
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.
Borislav Petkov113b5e32015-05-26 10:28:20 +020098
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.