The difference between the "go" process context and the interrupt context, atomic context

Kernel space and user space are two working modes of modern operating system, kernel modules run in kernel space, while user-state applications run in user space. They represent different levels and have different access rights to system resources. Kernel modules run at the highest level (kernel state), and all operations under this level are trusted by the system, and the application runs at a lower level (user state). At this level, the processor controls direct access to the hardware and non-authorized access to the memory. The kernel state and the user state have their own memory map, which is their own address space.

The concept of context is only possible when the two systems are different from the line state. User-Space applications, if you want to request system services, such as manipulating a physical device, to map the address of the device to the user space, must be implemented through a system call. (A system call is an interface function that the operating system provides to user space.) As shown in the following:

Through the system call, the user space application will enter the kernel space, the kernel represents the process running in the kernel space, which involves the context of the switch, user space and kernel space with different address mappings, universal or dedicated register group, and user space process to pass a lot of variables, parameters to the kernel, The kernel also saves some registers, variables, etc. of the user process so that the system calls back to the user space to continue execution, so-called process context, is a process at the time of execution, the CPU of all registers of the value, the state of the process and the content on the stack, when the kernel needs to switch to another process, it All States of the current process need to be saved, that is, the process context of the current process is saved so that when the process is executed again, the state of the switchover is resumed and execution continues.

Similarly, the hardware sends an interrupt signal to the CPU by triggering a signal, causing the kernel to call the interrupt handler and enter the kernel space. In this process, some of the hardware variables and parameters are also passed to the kernel, the kernel through these parameters for interrupt processing, the interrupt context can be understood as the hardware passed over these parameters and the kernel needs to save some of the environment, mainly the environment of the interrupted process.

The Linux kernel works in the process context or interrupts the context. The kernel code that provides the system invocation service runs on the process context on behalf of the application that originated the system call, and on the other hand, the interrupt handler runs asynchronously in the interrupt context. The interrupt context is independent of a particular process.

Kernel code running in the process context can be preempted (Linux2.6 support preemption). However, an interrupt context usually always occupies the CPU (although interrupts can be nested, but we do not generally) and cannot be interrupted. Because of this, the code running in the interrupt context is subject to some limitations and cannot do the following:

1. Sleep or 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. Try to get the semaphore

In order to protect the interrupt handle critical section resource, you cannot use mutexes. If the semaphore is not available, the code will sleep, producing the same situation as above and using spinlock if the 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. Accessing the virtual address of the user space

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 terminal 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.

One of the basic tenets of the kernel is that in the context of interrupts or atoms, the kernel cannot access user space and the kernel cannot sleep. That is, in this case, the kernel cannot invoke any function that could cause sleep. In general, the atomic context refers to an interrupt or soft interrupt, and when a spin lock is held. The kernel provides four macros to determine whether it is in these situations:

#define IN_IRQ () (Hardirq_count ())//In processing a hard interrupt
#define IN_SOFTIRQ () (Softirq_count ())//in handling soft interrupts
#define IN_INTERRUPT () (Irq_count ())//In the processing of a hard interrupt or soft interrupt
#define IN_ATOMIC () ((Preempt_count () & ~preempt_active)! = 0)//include all of the above

The count that these four macros access is thread_info->preempt_count. This variable is actually a bitmask. The minimum 8 bits represents a preemption count, usually modified by Spin_lock/spin_unlock, or the programmer enforces the modification, indicating that the maximum preemption depth allowed by the kernel is 256.
The 8-15-bit represents a soft interrupt count, usually modified by local_bh_disable/local_bh_enable, and indicates that the maximum allowable soft interrupt depth for the kernel is 256.
Bit 16-27 is a hard interrupt count, usually modified by ENTER_IRQ/EXIT_IRQ, and indicates that the maximum allowable hard interrupt depth for the kernel is 4096.
The 28th place is the preempt_active flag. The code representation is:
Preempt_mask:0x000000ff
Softirq_mask:0x0000ff00
hardirq_mask:0x0fff0000
All the above 4 macros return 1 to get the place is atomic context, is not allowed to access the kernel user space, not allow the kernel sleep, do not allow the call any function that may cause sleep. and on behalf of Thread_info->preempt_count not 0, this tells the kernel that the preemption is disabled here.
However, for in_atomic (), it works well when preemption is enabled, telling the kernel whether it currently holds a spin lock, whether preemption is disabled, and so on. However, if preemption is not enabled, Spin_lock does not modify preempt_count at all, so even if the kernel calls Spin_lock and holds the spin lock, In_atomic () will still return 0, and the error tells the kernel that it is currently in a non-atomic context. So it is problematic to rely on in_atomic () to determine whether the code in the atomic context is in the case of a forbidden preemption.

The difference between the "go" process context and the interrupt context, atomic context