Linux kernel signal __linux

This paper briefly introduces the Linux signal Processing mechanism, and makes a foreshadowing for introducing the signal processing mechanism under binary translation.
The main bibliography of this article "Linux Kernel source code scenario analysis" "The original product kernel: Linux kernel source code Guide"
first, let's say what a signal is. the signal is essentially a simulation of the interrupt mechanism at the software level, and its main sources are as follows: Program error: Except 0, illegal memory access ... External signal: Terminal CTRL-C produces sgint signal, timer expires SIGALRM ... Explicit request: The KILL function allows a process to send any signal to another process or process group.

Under Linux, you can view all of the system's signals by using the following command: Kill-l

You can send a signal explicitly to a process by using a command similar to the following: Kill-2 PID

The above command sends a 2nd signal to the process with the process ID PID. No signal with number 0 is present.

Linux currently supports 64 kinds of signals. The signals are divided into non-real-time signals (unreliable signals) and real-time signals (reliable signals) of two types, corresponding to the Linux signal value of 1-31 and 34-64. The signal is asynchronous, a process does not have to do anything to wait for the signal to arrive, in fact, the process does not know exactly when the signal arrived. This article focuses on the Linux signal Processing mechanism, more information on the signal can be referred to here.

Typically, when a process receives a signal, the following behavior occurs:

The response of a process to a signal ignores the signal: most of the signals can be ignored, except for Sigstop and Sigkill signals (which are the means by which Superuser kills or deactivates any process). Capture signal: Registers a signal processing function that deals with specific signals that are generated. Let the signal default action work: the default action defined by the Unix kernel, in 5 cases: a) Miscarriage abort: Terminates the process and produces the core file. B Stop STOP: Terminate the process without generating the core file. c) Ignore: Ignore signal. d) Suspend suspend: Suspend process. E) Continue continue: If the process is suspended, then resume the process, otherwise ignore this signal.

registering signal processing functions

If you want the process to capture a signal, and then make the appropriate processing, you need to register the signal processing function. Like interrupts, the kernel also prepares a signal vector table for each process, which records the processing mechanism for each signal in the signal vector table, by default, by invoking the default processing mechanism. When a process registers a signal handler for a signal, the kernel invokes the registered function when the signal is taken.

The registration signal processing function is called by the system signal (), sigaction (). The signal () is implemented on the basis of reliable signal system invocation, which is the library function. It has only two parameters, does not support signal transmission information, is mainly used for the first 32 kinds of non-real-time signal installation, while Sigaction () is a newer function (implemented by two system calls: Sys_signal and Sys_rt_sigaction), with three parameters that support signal transmission information, Mainly used in conjunction with Sigqueue () system calls, of course, sigaction () also supports the installation of non-real-time signals. Sigaction () is superior to signal () mainly embodied in the support signal with parameters. If you want to get more information about this, you can also refer to this. the signal processing mechanism under Linux

how the process discovers and accepts signals.

We know that the signal is asynchronous, a process can not wait for the arrival of the signal, also do not know the signal will come, then, how the process is to find and accept the signal. In fact, the reception of the signal is not done by the user process, but by the kernel agent. When a process P2 the signal to another process P1, the kernel receives the signal and places it in the P1 signal queue. When P1 into the kernel state again, the signal queue is checked and the corresponding signal processing function is adjusted according to the corresponding signal. As shown in the following illustration:

Where the action C: Detect and capture signals

signal detection and response time

As we said just now, when P1 into the kernel again, it checks the signal queue. So when will P1 be stuck in the kernel again? When you get stuck in the kernel, you will detect the signal queue at what time. The current process enters the system space as a result of system calls, interrupts, or exceptions, returning from system space to the eve of user space. The current process is first awakened when it enters sleep in the kernel (must be in a system call), or is returned to user space early due to the presence of a signal that cannot be ignored.

enter signal processing function

After discovering the signal, according to the signal vector, know the processing function, then how to enter the signal processing program, how to return it.

We know that the user process provides the signal processing function is in the user state, and we found the signal to find the signal processing function at the moment in the kernel state, so we need to run from the kernel state to the user state to execute Signal processing program, after the completion of the return to the kernel state. This process is shown in the following illustration:

As you can see in the picture, the whole process of processing a signal is this: process due to system calls or interrupts into the kernel, the completion of the corresponding task to return to the user space on the eve, check the signal queue, if there is a signal, according to the signal vector table to find the signal processing function, set the "frame", jump to the user state to perform signal processing functions. After the signal processing function completes, returns the kernel state, sets "frame", and returns to the user state to continue executing the program.

In the above passage, I mentioned "frame", what frame is. So why do you want to set the frame. Why do I have to return the kernel state after executing the signal processing function?

what is called frame.

When a subroutine is invoked, the stack is stretched down (logically upward) because the return address of the subroutine needs to be saved in the stack, and because subroutines often have local variables and occupy space in the stack. In addition, the arguments are on the stack when the subroutine is invoked. The deeper the subroutine calls nesting, the more layers the stack stretches. Each of these levels in the stack is called a "frame", or frame.

Generally speaking, when the subroutine and the program that calls it in the same space, the extension of the stack, that is, the building of the framework in the stack, the process is mainly as follows: The call instruction presses the return address into the stack (automatic) to allocate local variables by pressing the push instruction into the calling parameter adjustment

why and how to set the frame.

We know that when a process falls into the kernel state, the interrupt scene is saved in the stack. Because the user state and the kernel state are two running levels, there are two different stacks to use. When a user process has just entered the kernel through a system call, the CPU automatically presses the contents of the following image in the kernel stack of the process: (figure from the Linux kernel full comment)

After the system call is processed, the do_signal () function is invoked to set the frame and so on. The state of the kernel stack should be similar to the left half of the image below (the system call pushes some information onto the stack):

After the signal processing function is found, the Do_signal function first saves the EIP in the kernel stack as the OLD_EIP, then replaces the EIP with the address of the signal processing function, and then subtracts the "original ESP" (that is, the user state stack address) from the kernel to a certain value. The goal is to expand the user-state stack, then save the contents of the kernel stack on the user stack, which is to set the frame. It is worth noting that the following two points: the value of the EIP is set to the address of the signal processing function, because once the process returned to the user state, it is necessary to execute the signal processing program, So the EIP should point to the signal processing program rather than the address that should have been executed. The reason to copy the frame from the kernel stack to the user stack this is because the process of returning user state from the kernel will clean up the kernel stack (like a function call) used in this call, and the kernel stack is too small to simply save another frame on the stack (imagine nesting signal processing). And we need to EAX (System call return value), EIP this information to execute the signal processing function can continue to execute the program, so copy them to the user state stack to save.

After the above is clear, the following things are much smoother. When the process returns user space, the signal processing function is executed according to the EIP value in the kernel stack. So, after the signal processing program finishes, how to return the program to continue execution.

what to do after the signal processing function is done.

After the completion of the signal processing program, the process will actively call the Sigreturn () system call back to the kernel again, see if there is any other signal to deal with, if not, then the kernel will do some clean-up work, will be saved before the frame restored to the core stack, restore the value of the EIP Old_eip, Then the user space is returned and the program can continue to execute. At this point, the kernel has completed one (or several) signal processing work.