why does the process yield control flow to kernel when it knows how to handle?

Question

My understanding is as follows.

1. The program raises runtime errors (e.g., division by zero, or invalid memory reference)
2. The program executes 'fault' instruction and give control to the kernel
3. The kernel determines that it is not recoverable like page fault, so it sends the proper signal to the process (e.g., SIGFPE / SIGSEGV)
4. The process receives the signal and exits itself.

If the operations described above makes sense, I don't understand the designs or rationales for the process above. In my understanding the program at first place know that it is an obvious error (at the step 1 - before it gave its control to the kernel). Then, why does the process not exit at that time but rather do some operations? (step 2-4)

Answer 1

The program likely doesn't realize that it is engaging in illegal behavior (e.g., divide by 0), otherwise it probably wouldn't have engaged in the behavior in the first place. And regardless, perhaps the program does know that it is engaging in illegal behavior because it is trying to attack the system. When this behavior takes place, the hardware actually traps to the kernel and reports what the issue is. The kernel then sends a signal to the userspace process, and the process may have a chance to recover (or not). This series of steps protects the hardware and the operating system from a malfunctioning program, whether the malfunction is accidental or on purpose.

Thus, in your step (2), the program is not issuing a specific fault instruction. It just engages in the behavior (e.g., a div with a divisor of 0) and that behavior triggers the hardware to take over. This is why steps 2-4 are necessary -- otherwise, the hardware and operating system could not protect themselves from a rogue userspace process.

Note that sometimes programs deliberately engage in illegal behavior to unlock new functionality. See slide 40 in these lecture notes for more details.