I am reading "Linux Kernel Development" by Robert Love and he wrote that the system call executes in process context and is capable of sleeping. The current pointer will refer to the current task, which is the process that issued the system call.

What I don't understand is if a system call can sleep, how does execution return to the system call? If it runs in process context, it could be awakened and re-scheduled, but user processes cannot execute in kernel space. Does the kernel create a task/process to execute the system call when it is called? I know the system call from user space causes a trap to switch to kernel mode and execute the corresponding system call, but I was under the assumption before reading this that system calls couldn't sleep and be rescheduled, but I understand why they should be able to.

2 Answers 2


The key part is this:

user processes cannot execute in kernel space

This is incorrect. When Robert Love writes that the system call executes in process context, basically it means that the process runs in kernel mode to run the system call. When the kernel is handling a system call, it’s still running in a process, the calling process. If it decides to re-schedule, the process is suspended, and execution continues in whatever other process is scheduled instead.

When the suspended process resumes, it continues execution in the system call, in kernel mode.

The big change in 2.6 with regards to scheduling was that previously, processes could only be interrupted in user mode; with a pre-emptible kernel, processes can also be interrupted in kernel mode (except when they disable pre-emption, which is done around critical sections of kernel code).

  • Since the user process can run in kernel mode, does that mean when it is suspended in kernel mode, it will be rescheduled with the other kernel processes? And once it returns from the system call, it will be scheduled with the user processes? I am now confused as to when the process is rescheduled in kernel mode, how it runs in kernel mode when it's rescheduled? I have never read anything about the mode (user or kernel) being saved or set when context switching.
    – Hoffman
    Sep 4, 2019 at 14:19
  • A context switch always happens in kernel mode. What happens next depends on the process state. If the process is running in user mode, the kernel will return to it, leaving kernel mode in the process. If the process was interrupted in kernel mode, the kernel will continue what it was doing. Sep 4, 2019 at 16:37

A user process cannot run from kernel space, let's not confusing readers. Whatever operation, being a read() a ioctl() or whatever, passes through the libc, ending in the "syscall" assembly instruction (x86_64). This results in a sw interrupt, and it's a bridge to kernel space, that returns the control to userspace when the handler completes.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .