Am 12. November 2020 21:45:56 MEZ schrieb "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx>: >On 11/12/20 5:25 PM, Heinrich Schuchardt wrote: > >[...] > >> Hello Michael, >> >> this text is very helpful. >> >> "Signal mask and pending signals" already mentions that the signal >mask >> controls the blocking of signals. But maybe you could reiterate this >in >> 1d) and in the note below 5). > >Yes, that perhaps does not hurt. Some light tweaks: > > Execution of signal handlers > Whenever there is a transition from kernel-mode to user-mode exe‐ > cution (e.g., on return from a system call or scheduling of a > thread onto the CPU), the kernel checks whether there is a pending > signal for which the process has established a signal handler. If > there is such a pending signal, the following steps occur: > > 1. The kernel performs the necessary preparatory steps for execu‐ > tion of the signal handler: > > a) The signal is removed from the set of pending signals. > > b) If the thread has defined an alternate signal stack (using > sigaltstack(2)), then that stack is installed. > > c) Various pieces of signal-related context are saved into a > "hidden" frame that is created on the stack. The saved in‐ > formation includes: > > + the program counter register (i.e., the address of the > next instruction in the main program that should be exe‐ > cuted when the signal handler returns); > > + the thread's current signal mask; > > + the thread's alternate signal stack settings. > > d) The thread's signal mask is adjusted by adding the signal > (unless the handler was established using the SA_NODEFER > flag) as well as any additional signals specified in > act->sa_mask when sigaction(2) was called. These signals > are thus blocked while the handler executes. > > 2. The kernel constructs a frame for the signal handler on the > stack. Within that frame, the return address points to a piece > of user-space code called the signal trampoline (described in > sigreturn(2)). > > 3. The kernel passes control back to user-space, where execution > commences at the start of the signal handler function. > > 4. When the signal handler returns, control passes to the signal > trampoline code. > > 5. The signal trampoline calls sigreturn(2), a system call that > uses the information in the "hidden" stack frame to restore the > thread's signal mask and alternate stack settings to their > state before the signal handler was called. Upon completion of > the call to sigreturn(2), the kernel transfers control back to > user space, and the thread recommences execution at the point > where it was interrupted by the signal handler. > > Note that if the signal handler does not return (e.g., control is > transferred out of the handler using sigsetjmp(3) or swapcon‐ > text(3), or the handler executes a new program with execve(2)), > then the final step is not performed. In particular, in such sce‐ > narios it is the programmer's responsibility to restore the state > of the signal mask, if it is desired unblock the signals that were > blocked on entry to the signal handler. Is there a function to change the signal mask without leaving the handler? Otherwise looks good to me. Best regards Heinrich > >Thanks, > >Michael
