16

In a multitasking system when any hardware generates a interrupt to a particular CPU, where CPU can be performing either of below cases unless it is already serving a ISR:

  1. User mode process is executing on CPU
  2. Kernel mode process is executing on CPU

Would like to know which stack is used by interrupt handler in above two situations and why ?

Sunil Bojanapally
  • 12,528
  • 4
  • 33
  • 46

3 Answers3

16

All interrupts are handled by kernel. That is done by interrupt handler written for that particular interrupt. For Interrupt handler there is IRQ stack. The setup of an interrupt handler’s stacks is configuration option. The size of the kernel stack might not always be enough for the kernel work and the space required by IRQ processing routines. Hence 2 stack comes into picture.

  1. Hardware IRQ Stack.
  2. Software IRQ Stack.

In contrast to the regular kernel stack that is allocated per process, the two additional stacks are allocated per CPU. Whenever a hardware interrupt occurs (or a softIRQ is processed), the kernel needs to switch to the appropriate stack. Historically, interrupt handlers did not receive their own stacks. Instead, interrupt handlers would share the stack of the running process, they interrupted. The kernel stack is two pages in size; typically, that is 8KB on 32-bit architectures and 16KB on 64-bit architectures. Because in this setup interrupt handlers share the stack, they must be exceptionally frugal with what data they allocate there. Of course, the kernel stack is limited to begin with, so all kernel code should be cautious.

skaushal
  • 695
  • 3
  • 11
  • Hmm, My understanding is that there's only one interrupt stack. Do you have sources for the "software IRQ stack" and "hardware IRQ stack" ? – srd Feb 27 '15 at 21:49
  • 1
    @srd I have couple of references. Please go through: 1. Understanding the Linux Kernel: chapter4 interrupt handling https://books.google.co.in/books?id=h0lltXyJ8aIC&pg=PT177&lpg=PT177&dq=linux+kernel+irq+stack+softirq&source=bl&ots=gO1qF03gMU&sig=ckGWk2I0CnxBCi0meVUkvqZrv8A&hl=en&sa=X&ei=ninxVNW7MMSiugSk24LwCw&ved=0CB0Q6AEwAA#v=onepage&q=linux%20kernel%20irq%20stack%20softirq&f=false 2. Professional Linux Kernel Architecture: chapter 14 3. stackoverflow question: http://stackoverflow.com/questions/28115819/hardirq-stack-and-softirq-stack-for-linux-kernel-on-i386-arch – skaushal Feb 28 '15 at 02:57
  • 2
    This answers to some extent. I am actually looking what happens when currently executing task is user/kernel. However I found the answer myself. If in case Interrupt is going to executed at user level, a TSS stack switch occurs to its corresponding kernel stack, and if it is executed at same privilege level as kernel it uses the interrupted kernel stack. – Sunil Bojanapally Mar 02 '15 at 12:34
  • 1
    Any idea what happens if stack overflow happens in kernel level interrupt handler function?? In this case registered exceptional handler will be called ? – Pushpendra Apr 07 '17 at 07:14
  • If an interrupt or exception handler is called through an interrupt gate, the processor clears the interrupt enable (IF) flag in the EFLAGS register to prevent subsequent interrupts from interfering with the execution of the handler. An ISR has to be atomic and no one should be able to preempt the ISR. So all the interrupts are disabled on local CPU except NMI. When a given interrupt handler is executing, the corresponding interrupt line is masked out on all processors, preventing another interrupt on the same line from being received. Normally all other interrupts are enabled on other CPUs. – skaushal Aug 09 '18 at 05:36
  • @skaushal : Its always a good idea to give a reference. For example, your answer are lines taken from Page 122, Linux Kernel Development, 3rd Edition by Robert Love. – Naveen Sep 07 '20 at 12:29
  • "regular kernel stack is allocated per process" = incorrect. "regular kernel stack is allocated for every process thread" = correct. proof = https://www.kernel.org/doc/html/latest/x86/kernel-stacks.html – Alex Jun 14 '22 at 20:14
2

Interrupts are only handled by the kernel. So it is some kernel stack which is used (in both cases).

Interrupts do not affect (directly) user processes.

Processes may get signals, but these are not interrupts. See signal(7)...

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • I don't know if someone answer me, but I ask for something. What if interrupt handler allows further interrupts and this causes that kernel stack overflow ... what's the solution of this situation? – Nik Novák Dec 29 '15 at 23:04
0

Historically, interrupt handlers did not receive their own stacks. Instead, they would share the stack of the process that they interrupted. Note that a process is always running. When nothing else is schedulable, the idle task runs.

The kernel stack is two pages in size:

8KB on 32-bit architectures.

16KB on 64-bit architectures.

Because of sharing the stack, interrupt handlers must be exceptionally frugal with what data they allocate there.

Early in the 2.6 kernel process, an option was added to reduce the stack size from two pages to one, providing only a 4KB stack on 32-bit system, and interrupt handlers were given their own stack, one stack per processor, one page in size. This stack is referred to as the interrupt stack.

Although the total size of the interrupt stack is half that of the original shared stack, the average stack space available is greater because interrupt handlers get the full page of memory to themselves, because previously every process on the system needed two pages of contiguous, nonswappable kernel memory. Your interrupt handler should not care what stack setup is in use or what the size of the kernel stack is. Always use an absolute minimum amount of stack space

https://notes.shichao.io/lkd/ch7/#stacks-of-an-interrupt-handler

SK17
  • 182
  • 4
  • 15