Say that a process made a system call to open a file, when the Linux kernel executes this system call, the Linux kernel should add the fd for the opened file to the process fd table that made the system call.

How does the Linux kernel knows which process made this system call when the arguments passed to the system call do not include the PID?

closed as off-topic by mdpc, Anthony Geoghegan, Archemar, rudimeier, Kusalananda May 12 '17 at 20:17

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Requests for learning materials (tutorials, how-tos etc.) are off topic. The only exception is questions about where to find official documentation (e.g. POSIX specifications). See the Help Center and our Community Meta for more information." – mdpc, Archemar, Kusalananda
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 4
    What level of understanding are you looking for? The simple answer is "the kernel decides which process is running on each CPU thread (core), and only a running process can make a syscall—so clearly, it came from the running process" – derobert May 11 '17 at 20:42

A kernel system call executes within the context of the calling process, just at a different privilege level and with different support infrastructure. The Linux kernel has a per-CPU variable which tracks the current process, current_task; it uses that whenever it needs to know what the current process is. On a given CPU, the current task only changes when the scheduler decides, and the context switch takes care to save all the necessary information so that the kernel can keep track of what’s happening where.

LWN has a couple of useful articles on syscalls, Anatomy of a system call part 1 and part 2. They explain how system calls are defined and how they are executed, albeit perhaps not with enough detail to actually answer your question since they don’t cover the transition from user-space to kernel-space in detail; but that’s “just” whatever trap-based transition support is available on the CPU.


Your question suggests the application knows and manage its own PID and should pass it to the kernel for the latter to know how to do its job. This is a common misconception. The way this information flows is actually the other way around. A process doesn't need to know or store its process id, file descriptor tables and similar. If it wants to get information about them, it needs to retrieve it from the kernel using system calls like getpid, ioctl and the like.

While the kernel is made of a big bunch of source code lines, it is not a single program running on its side, with userland programs being living on the other side and sending requests to the kernel like say a web browser is sending requests to a web server. The system call parameters and return value are not the unique information flowing between the application and the kernel and all the low level information about every thread and process, whatever their state (running, waiting, sleeping…), is stored in the kernel memory.

You should see a large part of the kernel code like a big library, kind of linked with every running process on the system. When a process (actually a thread) performs a system call, it just dive into that special library and get super powers for a small period of time. But it is still the very same thread, so the kernel has all the information required to identify and manage the running thread like its owner, group, pid, file descriptors tables, and so on because it is precisely the kernel (here the scheduler) which assigns threads to available (v)CPUs.

  • Your answer does not adequately explain how the kernel knows which process is active. Describing it as a big library kind of works, but how does the library code which process it's running on behalf of? – Gilles May 12 '17 at 0:33

Not the answer you're looking for? Browse other questions tagged or ask your own question.