19

I am newbie to Linux Kernel.
I know that there are two context
1. Process Context, running in user space or in Kernel Space (for ex: as part of System call)
2. Interrupt Context

In what context Kernel Thread (not related to any User Thread, for ex:flush task) runs ?

Is there any other context other than Process and Interrupt context in Linux Kernel ?

user405369
  • 427
  • 1
  • 3
  • 8

3 Answers3

19

Kernel threads run in process contexts in kernel space. Though there are some kernel threads which handle interrupts too. They are called threaded interrupt handlers. But they still run in process context!

Here is an excellent explanation of the vital difference between the 2 contexts!

Here is one which'll help you gain more understanding!

What context does the scheduler code run in?

As far as I know, process and interrupt are the only 2 contexts.

Hassan
  • 870
  • 13
  • 25
Pavan Manjunath
  • 27,404
  • 12
  • 99
  • 125
  • 7
    Essentially the *point* of kernel threads is to allow the kernel to execute code in process context, but not directly on behalf of a particular userspace process. – caf Feb 22 '12 at 06:55
  • @Pavan: Threaded interrupt handlers (softirqs) exhibit the characteristics of interrupt context (you may not sleep), so claiming they are process context is contradictory. – jørgensen Feb 23 '12 at 12:56
  • @jørgensen If you read the GPIO documentation here-http://www.kernel.org/doc/Documentation/gpio.txt, it says- `Accessing such GPIOs requires a context which may sleep, for example a threaded IRQ handler` So it implies that threaded interrupt handlers can sleep right? You are right about softirqs. But they aren't the only kind of threaded interrupt handlers right? Or, even, does it really refer to softirqs when they say threaded interrupt handler? – Pavan Manjunath Feb 23 '12 at 18:03
  • Softirqs are orthogonal to threaded interrupts. Threaded interrupt handlers come from the -rt (realtime) tree, where you want to avoid unpredictable latency at all costs, so you can run some interrupt handlers in a separate thread that can be (de-)prioritized. – ninjalj Feb 23 '12 at 20:49
4

There is a handful of states—some may be specializations of others. Also see http://www.kernel.org/doc/htmldocs/kernel-hacking.html .

  • NMI context (in_nmi())
  • hard interrupt context (in_irq())
  • soft interrupt context (in_softirq())
  • (tasklet, timer, and workqueue contexts)
  • atomic context (in_atomic()). Possibly entryways are, among others, spin_lock.
  • RCU context, enter with rcu_read_lock for example
  • user context
jørgensen
  • 10,149
  • 2
  • 20
  • 27
0

Well there are certain tasks that are neither called via a system call or when handling interrupts. Such are handled as pure kernel contexts, for instance the swapper, the INIT_TASk etc which do not have corresponding code running in the user space.

Gargi Srinivas
  • 929
  • 6
  • 6