4. Kernel Stacks¶
4.1. Kernel stacks on x86-64 bit¶
Most of the text from Keith Owens, hacked by AK
x86_64 page size (PAGE_SIZE) is 4K.
Like all other architectures, x86_64 has a kernel stack for everyactive thread. These thread stacks are THREAD_SIZE (2*PAGE_SIZE) big.These stacks contain useful data as long as a thread is alive or azombie. While the thread is in user space the kernel stack is emptyexcept for the thread_info structure at the bottom.
In addition to the per thread stacks, there are specialized stacksassociated with each CPU. These stacks are only used while the kernelis in control on that CPU; when a CPU returns to user space thespecialized stacks contain no useful data. The main CPU stacks are:
Interrupt stack. IRQ_STACK_SIZE
Used for external hardware interrupts. If this is the first externalhardware interrupt (i.e. not a nested hardware interrupt) then thekernel switches from the current task to the interrupt stack. Likethe split thread and interrupt stacks on i386, this gives more roomfor kernel interrupt processing without having to increase the sizeof every per thread stack.
The interrupt stack is also used when processing a softirq.
Switching to the kernel interrupt stack is done by software based on aper CPU interrupt nest counter. This is needed because x86-64 “IST”hardware stacks cannot nest without races.
x86_64 also has a feature which is not available on i386, the abilityto automatically switch to a new stack for designated events such asdouble fault or NMI, which makes it easier to handle these unusualevents on x86_64. This feature is called the Interrupt Stack Table(IST). There can be up to 7 IST entries per CPU. The IST code is anindex into the Task State Segment (TSS). The IST entries in the TSSpoint to dedicated stacks; each stack can be a different size.
An IST is selected by a non-zero value in the IST field of aninterrupt-gate descriptor. When an interrupt occurs and the hardwareloads such a descriptor, the hardware automatically sets the new stackpointer based on the IST value, then invokes the interrupt handler. Ifthe interrupt came from user mode, then the interrupt handler prologuewill switch back to the per-thread stack. If software wants to allownested IST interrupts then the handler must adjust the IST values onentry to and exit from the interrupt handler. (This is occasionallydone, e.g. for debug exceptions.)
Events with different IST codes (i.e. with different stacks) can benested. For example, a debug interrupt can safely be interrupted by anNMI. arch/x86_64/kernel/entry.S::paranoidentry adjusts the stackpointers on entry to and exit from all IST events, in theory allowingIST events with the same code to be nested. However in most cases, thestack size allocated to an IST assumes no nesting for the same code.If that assumption is ever broken then the stacks will become corrupt.
The currently assigned IST stacks are:
ESTACK_DF. EXCEPTION_STKSZ (PAGE_SIZE).
Used for interrupt 8 - Double Fault Exception (#DF).
Invoked when handling one exception causes another exception. Happenswhen the kernel is very confused (e.g. kernel stack pointer corrupt).Using a separate stack allows the kernel to recover from it well enoughin many cases to still output an oops.
ESTACK_NMI. EXCEPTION_STKSZ (PAGE_SIZE).
Used for non-maskable interrupts (NMI).
NMI can be delivered at any time, including when the kernel is in themiddle of switching stacks. Using IST for NMI events avoids makingassumptions about the previous state of the kernel stack.
ESTACK_DB. EXCEPTION_STKSZ (PAGE_SIZE).
Used for hardware debug interrupts (interrupt 1) and for softwaredebug interrupts (INT3).
When debugging a kernel, debug interrupts (both hardware andsoftware) can occur at any time. Using IST for these interruptsavoids making assumptions about the previous state of the kernelstack.
To handle nested #DB correctly there exist two instances of DB stacks. On#DB entry the IST stackpointer for #DB is switched to the second instanceso a nested #DB starts from a clean stack. The nested #DB switchesthe IST stackpointer to a guard hole to catch triple nesting.
ESTACK_MCE. EXCEPTION_STKSZ (PAGE_SIZE).
Used for interrupt 18 - Machine Check Exception (#MC).
MCE can be delivered at any time, including when the kernel is in themiddle of switching stacks. Using IST for MCE events avoids makingassumptions about the previous state of the kernel stack.
For more details see the Intel IA32 or AMD AMD64 architecture manuals.
4.2. Printing backtraces on x86¶
The question about the ‘?’ preceding function names in an x86 stacktracekeeps popping up, here’s an indepth explanation. It helps if the readerstares at print_context_stack() and the whole machinery in and aroundarch/x86/kernel/dumpstack.c.
Adapted from Ingo’s mail, Message-ID: <20150521101614.GA10889@gmail.com>:
We always scan the full kernel stack for return addresses stored onthe kernel stack(s)[1], from stack top to stack bottom, and print outanything that ‘looks like’ a kernel text address.
If it fits into the frame pointer chain, we print it without a questionmark, knowing that it’s part of the real backtrace.
If the address does not fit into our expected frame pointer chain westill print it, but we print a ‘?’. It can mean two things:
- either the address is not part of the call chain: it’s just stalevalues on the kernel stack, from earlier function calls. This isthe common case.
- or it is part of the call chain, but the frame pointer was not setup properly within the function, so we don’t recognize it.
This way we will always print out the real call chain (plus a few moreentries), regardless of whether the frame pointer was set up correctlyor not - but in most cases we’ll get the call chain right as well. Theentries printed are strictly in stack order, so you can deduce moreinformation from that as well.
The most important property of this method is that we _never_ loseinformation: we always strive to print _all_ addresses on the stack(s)that look like kernel text addresses, so if debug information is wrong,we still print out the real call chain as well - just with more questionmarks than ideal.
| [1] | For things like IRQ and IST stacks, we also scan those stacks, inthe right order, and try to cross from one stack into anotherreconstructing the call chain. This works most of the time. |