Does the kernel by default block pending signals when the process is in kernel mode?

Question

Computer Systems: a Programmer's Perspective says:

8.5.1 Signal Terminology

A pending signal is received at most once. For each process, the kernel main- tains the set of pending signals in the pending bit vector, and the set of blocked signals in the blocked bit vector.

8.5.3 Receiving Signals

When the kernel switches a process p from kernel mode to user mode (e.g., returning from a system call or completing a context switch), it checks the set of unblocked pending signals (pending & ~blocked) for p. If this set is empty (the usual case), then the kernel passes control to the next instruction (I next) in the logical control flow of p. However, if the set is nonempty, then the kernel chooses some signal k in the set (typically the smallest k) and forces p to receive signal k. The receipt of the signal triggers some action by the process. Once the process completes the action, then control passes back to the next instruction (I next) in the logical control flow of p.

1. Does the kernel by default block pending signals when the process is in kernel mode?

   Will the kernel set the bit in bit vector blocked, for a pending signal when the process is in kernel mode?

   Does the kernel by default block signals in that situation, in the same sense as "Implicit blocking mechanism" in the following quote?

   8.5.4 Blocking and Unblocking Signals

   Linux provides implicit and explicit mechanisms for blocking signals:

   Implicit blocking mechanism. By default, the kernel blocks any pending signals of the type currently being processed by a handler.

2. will the remaining pending signals that were pending when the process was in kernel mode be processed, after the chosen pending signal k finishes being processed? (The quote says "Once the process completes the action, then control passes back to the next instruction (I next) in the logical control flow of p.")

Thanks.

Answer 1

No, the kernel will not modify the blocked vector.

Signals are delivered to a process only on context switch from kernel mode to that process. Note, when a signal handler finishes, the process invokes sigreturn(2) to return control to the kernel.

As to 2, yes and no. Yes, the kernel will deliver any other pending signals the next time that process is scheduled to run. However, for most signals, multiple pending signals of the same kind, ie SIGCHLD, will only be delivered once. That's the implicit blocking described above.

Certain signals can interrupt a running signal handler, ie SIGSEGV when using SA_NODEFER (see sigaction(2)).