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
pendingbit vector, and the set of blocked signals in the
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 ﬂow 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 ﬂow of p.
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.
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 ﬂow of p.")