User mode and kernel mode switching during system calls

Question

On a broad level which of the following happens during a linux system call.

1. User mode process gets elevated to kernel mode and execute the kernel code(Interrupt Service routines) and then return back to normal mode. In other words it is the user process that is consuming CPU.
2. There is a kernel process that is always running in kernel mode. User mode processes dispatch tasks(in the form of system calls) to kernel process. Kernel process finishes the job and return the results to user mode processes. In other words user process is idle during this time and kernel process is the one consuming CPU.
3. Something else.

Answer 1

It is primarily 1 but a little bit of 2.

From the perspective of the usermode application, system calls themselves happen synchronously. Often times however, the system call does not have what it needs to return, so it puts the process to sleep. This doesn't always happen; some simple system calls do actually complete synchronously. Some however, need to wait for a long-running I/O task to complete.

The kernel has interrupt handlers and kernel threads that handle things asynchronously. An example would be that your hard drive interrupted the system to indicate that it finally retrieved that file you were reading. One of these asynchronous events can come along and wake up your process, now that the system call has what it needs to return to userspace.

So it looks like the whole process happened synchronously, but it was only an illusion.

Answer 2

In order for a processor to enter kernel (or another elevated) mode, it must do so through an interrupt or an exception. Because you are asking about system calls, we are dealing with exception.

[As the risk of gross oversimplification, especially Intel's strangeness...] Any hardware exception (e.g., access violation, divide by zero, page fault) causes the processor to enter kernel mode. Each exception has a number defined by the processor. When an exception occurs, the processor dispatches to an exception handler. Usually, the processor has registers that define the location and length of an array of exception handlers. When Exception #2 occurs, the CPU invokes the third handler in the array (0, 1, 2).

Processors invariable have instructions for triggering exceptions for specific purposes, such as debugging and system calls.

To make a system call, you invoke a processor instruction that causes an exception that dispatches to the exception handler that performs the system call. At the end of the system call, the handler invokes a special return from exception/interrupt instruction that returns the processor to user mode.

Thus, your #1 is largely correct.

Your #2 is completely wrong in most operating systems. Interrupts and exceptions are handled by the process that is currently executing (Linux uses different terminology but functionally it is the same).

If your process does a read to a disk, it will likely suspend while waiting for a respond. Another process will be running when the interrupt occurs signaling YOUR disk I/O is complete. THAT process will handle the interrupt for YOUR I/O. It will then queue your I/O request to your process and set you process state to runnable. The next time your process is schedule to run, it can pick up its completed I/O request.