CODEWITHSUNDEEP
linuxlinux-kerneloperating-system
johnny92
johnny92

Reputation: 95

What is "process context" exactly, and how does it relates to "interrupt context"?

What does the following phrase mean: "the kernel executes in the process context"?

Does it mean that if CPU is executing some process and then some interrupt occurs (system call, key press, etc.), the CPU will keep the page table for the currently running process loaded and then it will execute the interrupt handler which resides in the process's kernel space?

If this is what it means, then it seems like the interrupt handler is executed in the process context, so what does interrupt context means?

Upvotes: 4

Views: 13780

Answers (3)

Li Chen
Li Chen

Reputation: 5280

Process context and Interrupt context both mean the context your kernel code running in.

  • When the kernel is executing on behalf of a particular process, such as during various syscalls like open and close, this is known as the process context. It is considered safe to perform sleep operations, such as msleep or mutex within the process context. Kthreads operate within the context of a process and are created as a fork from kthreadd:
# ps axf | grep kthread
      2 ?        S      0:00 [kthreadd]
     12 ?        I      0:00  \_ [rcu_tasks_kthread]
     13 ?        I      0:00  \_ [rcu_tasks_rude_kthread]
     14 ?        I      0:00  \_ [rcu_tasks_trace_kthread]
 170952 pts/14   S+     0:00          \_ grep --color=auto kthread
  • When referring to kernel codes that are not bound to specific userspace processes and have disabled interrupts, we use the term interrupt contex. It is not safe to sleep under interrupt context. The top half irq handler usually runs under interrupt context, as do bottom half functions like softirq, which also disable interrupts. However, not all IRQ handlers run under interrupt context. In the PREEMPT_RT kernel, all top halves run inside kthread (see irq_work for details), so they run under process interrupt instead (although still at a very low level and under interrupt context). Additionally, softirq becomes preemptable under this kernel, so it no longer runs under interrupt context.

Upvotes: 1

typedeaf
typedeaf

Reputation: 1661

A process context is code running in the kernel, on behalf of a user process (syscall or exception) or kernel thread.

An interrupt context is code running in the kernel due to a hardware interrupt; its running an Interrupt Service Routine triggered from a hardware IRQ.

The need to differentiate the two is not 100% clear to me. I believe the significance is in priority. Something in process context can be preempted out so that IRQ can be quickly serviced.

Upvotes: 0

Tony Tannous
Tony Tannous

Reputation: 14871

Process context is its current state. We need to save the context of the current running process so it can be resumed after the interrupt is handled.

Process context is basically its current state (what is in its registers). 

esp
ss
eip
cs
and more.

We need to save the instruction pointer (EIP) and the CS (Code Segment) so that after the interrupt is handled we can continue running from where we were stopped.

The interrupt handler code resides in Kernel memory. Once an interrupt occur, we immediately switch from user mode to kernel mode. The state of the current running process is saved, part of it on user-stack and the other part on kernel-stack (depending on architecture). Assuming it's x86 then the interrupt handler is run by loading the appropriate ss, cs, esp and eip from TSS and Interrupt descriptor table.

Upvotes: 8

Related Questions