Lines Matching refs:stack

21 Kernel stack overflows are often hard to debug and make the kernel
25 Virtually-mapped kernel stacks with guard pages causes kernel stack
31 causes reliable faults when the stack overflows. The usability of
32 the stack trace after overflow and response to the overflow itself
49   needs to work while the stack points to a virtual address with
51   most likely) needs to ensure that the stack's page table entries
52   are populated before running on a possibly unpopulated stack.
53 - If the stack overflows into a guard page, something reasonable
64   with guard pages. This causes kernel stack overflows to be caught
75         VMAP_STACK is enabled, it is not possible to run DMA on stack
86 When a new kernel thread is created, thread stack is allocated from
91 alloc_thread_stack_node() calls __vmalloc_node_range() to allocate stack
101   that VMAP'd stack overflow detection works correctly. Arch specific
102   vmap stack allocator takes care of this detail.
105 Thread stack allocation is initiated from clone(), fork(), vfork(),
107 the code base to understand when and how thread stack is allocated.
113 stack and a non-null stack_vm_area pointer serves as a indication that the
123 Leading and trailing guard pages help detect stack overflows. When stack
125 the stack again. When handlers are called, it is likely that very little
126 stack space is left.
129 stack overflow on the double-fault stack.
147   high-order stack allocation, at least when the cache hits.
151 - The thread stack can be free'ed as soon as the task is dead (without
153   entire stack for reuse on the same cpu.