Process context and interrupt context

The recent learning driver has always found that the process context and interrupt context are mentioned in some materials or books, but none of them explain what the context is, so I read the information to supplement the so-called Linux context knowledge. (Note: The following knowledge degrees Niang come)

Context:

An article or speech connected to a word or sentence above and below: the meaning of the word contact context is not difficult to understand. Do not know who made a so obscure words, translation into context and environment much better understanding.

(Note: Above is the degree Niang to the ancient scholar poets Creation this word encyclopedia)

A paragraph in the Linux full annotation: When a process executes, the values in all registers of the CPU, the state of the process, and the contents of the stack are referred to as the context of the process. When the kernel needs to switch to another process, it needs to save all the state of the current process, that is, to save the context of the current process so that it can be executed when the process is executed again. In Linux, the current process context is stored in the task data structure of the process. In the event of an outage, the kernel executes the interrupt service routine under the kernel state in the context of the interrupted process. At the same time, all resources that need to be used are preserved so that the execution of the interrupted process can be resumed at the end of the relay service.

It is known from the above:

The process context:

When a process executes, the values in all registers of the CPU, the state of the process, and the contents of the stack

The context of a process can be divided into three parts: User-level context, register context, and system-level contexts.
User-level context: body, data, user stack, and shared storage;
Register Context: Universal Register, Program Register (IP), processor status register (eflags), stack pointer (ESP);
System-Level context: Process Control block task_struct, memory management information (mm_struct, Vm_area_struct, PGD, Pte), kernel stacks.

When a process is scheduled, a process switch is a context switch. The operating system must switch all the information mentioned above to run the newly scheduled process. The system call is a mode switch. Mode switching is much easier compared to process switching, and saves time because the main task of mode switching is to switch the process register context.

Interrupt the context:

When a process breaks, first save the current process context information, and then jump to interrupt subroutine to execute, then in the interrupt subroutine will produce the current stack and register equivalence is called

The interrupt context.

The kernel enters the interrupt context because of interrupt processing or soft interrupts caused by the interruption of the signal. The interrupt signal is random, the interrupt handler and the soft interrupt do not predict in advance which process is currently running in the event of an outage.

The processor is always in one of the following states:
1, the kernel state, running in the process context, the kernel represents the process running in the kernel space;
2, the kernel state, running in the interrupt context, the kernel represents the hardware running in the kernel space;
3, user state, running in user space.

The kernel can be in two contexts: the process context and the interrupt context. After the system call, the user application enters the kernel space, after which the kernel space is run on the process context for the representative of the corresponding process for the user space. An asynchronous interrupt causes the interrupt handler to be called, and the interrupt handler runs in the interrupt context. The interrupt context and process context cannot occur at the same time.

Kernel code running in the process context is preempted, but the interrupt context runs until the end and is not preempted. Therefore, the kernel restricts the operation of the interrupt context and does not allow it to do the following:

1) Go to sleep or actively abandon the CPU;

Since the interrupt context does not belong to any process, it has nothing to do with current (although at this point the current points to the interrupted process), the interrupt context cannot be awakened once it sleeps or discards the CPU. Therefore also called atomic context (atomic context).

2) occupy the mutex;

To protect the interrupt handle critical section resource, you cannot use a mutex (mutexes). If the semaphore is not received, the code will sleep, producing the same situation as above and using a spin lock (spinlock) If a lock must be used.

3) Perform time-consuming tasks;

Interrupt processing should be as fast as possible, because the kernel responds to a large number of services and requests, and the interrupt context takes too long CPU time to severely affect system functionality. When performing time-consuming tasks in an interrupt-handling routine, it should be referred to the bottom half of the interrupt handling routine.

4) access to the user space virtual memory.

Because the interrupt context is independent of a particular process, it is the kernel that is running in kernel space on behalf of the hardware, so the virtual address of the user space cannot be accessed in the interrupt context

5) Interrupt processing routines should not be set to reentrant (routines that can be invoked in parallel or recursively).

Because the interrupt occurs, both the preempt and the IRQ are disable until the interrupt is returned. So the interrupt context is not the same as the process context, and the different instances of the interrupt processing routines are not allowed to run concurrently on the SMP.

6) Interrupt processing routines can be interrupted by a higher-level IRQ.

If you want to prohibit this interruption, you can define the interrupt processing routine as a fast-processing routine, which is equivalent to telling the CPU that the routine is running and that all interrupt requests on the local CPU are blocked. As a direct result, the performance of the system degrades due to the delayed response of other interrupts.

(Note: Although kernel modules are not executed in the same order as the application, most of the actions performed by the kernel represent a particular process.) The kernel code can refer to the current process by accessing the global key, which is defined in <asm/current.h>, which produces a pointer to the structure task_struct, defined in <linux/sched.h>. The current pointer points to the currently running process. During a system call execution, such as open or read, the current process is the process that made the call. Kernel code can use the process-specific information by using current, if it needs to.)

Process context and interrupt context