Where is the process descriptor structure stored

Note that the kernel stack is used only for kernel routines, and the Linux kernel also provides separate hard interrupt stacks and soft interrupt stacks for interrupts.

Shows how to store two kinds of data structures in physical memory. The thread descriptor resides with the beginning of this memory area, while the top end of the stack grows downward. From ULK3, the process kernel stack is associated with a process descriptor such as:. In the 80x86 system, the stack starts at the top and grows in the direction of the memory area. The kernel stack of the process is always empty after the user state has just switched to the kernel state. Therefore, the ESP register points to the top of the stack.

Once the data is written to the stack, the value of ESP is decremented. A federation is used in the Linux kernel to represent the thread descriptors and kernel stacks of a process:. Also, the starting start address for the two page boxes is aligned. Information that reacts to the status of the process, but not the running state, for the kernel to identify the current state of the process for next steps.

The possible values of the flags members are as follows, with the macros starting with PF Processflag. In a Linux system, there is a direct or indirect connection between all processes, each of which has its parent process, and possibly 0 or more child processes.

All processes that have the same parent process have a sibling relationship. This article is an English version of an article which is originally in the Chinese language on aliyun. This website makes no representation or warranty of any kind, either expressed or implied, as to the accuracy, completeness ownership or reliability of the article or any translations thereof. Often, immediately after a fork it is desirable to execute a new, different, program.

In modern Linux kernels, fork is actually implemented via the clone system call, which is discussed in a following section. Finally, a program exits via the exit system call. This function terminates the process and frees all its resources.

A parent process can inquire about the status of a terminated child via the wait4 2 system call, which enables a process to wait for the termination of a specific process. When a process exits, it is placed into a special zombie state that is used to represent terminated processes until the parent calls wait or waitpid.

Another name for a process is a task. The Linux kernel internally refers to processes as tasks. In this book, I will use the terms interchangeably, although when I say task I am generally referring to a process from the kernel's point of view.

The kernel stores the list of processes in a circular doubly linked list called the task list 3. The process descriptor contains all the information about a specific process. This size, however, is quite small considering that the structure contains all the information that the kernel has and needs about a process.

The process descriptor contains the data that describes the executing program—open files, the process's address space, pending signals, the process's state, and much more see Figure 3. Figure 3. Prior to the 2. This allowed architectures with few registers, such as x86, to calculate the location of the process descriptor via the stack pointer without using an extra register to store the location. See Figure 3. The new structure also makes it rather easy to calculate offsets of its values for use in assembly code.

The system identifies processes by a unique process identification value or PID. Because of backward compatibility with earlier Unix and Linux versions, however, the default maximum value is only 32, that of a short int , although the value can optionally be increased to the full range afforded the type.

The kernel stores this value as pid inside each process descriptor. This maximum value is important because it is essentially the maximum number of processes that may exist concurrently on the system. Although 32, might be sufficient for a desktop system, large servers may require many more processes. The lower the value, the sooner the values will wrap around, destroying the useful notion that higher values indicate later run processes than lower values.

Consequently, it is very useful to be able to quickly look up the process descriptor of the currently executing task, which is done via the current macro. This macro must be separately implemented by each architecture. The assembly is shown here:. This assumes that the stack size is 8KB. When 4KB stacks are enabled, is used in lieu of Thus, current on PPC merely returns the value stored in the register r2. PPC can take this approach because, unlike x86, it has plenty of registers.

Because accessing the process descriptor is a common and important job, the PPC kernel developers deem using a register worthy for the task. The state field of the process descriptor describes the current condition of the process see Figure 3. Each process on the system is in exactly one of five different states. This value is represented by one of five flags:. This is the only possible state for a process executing in user-space; it can also apply to a process in kernel-space that is actively running.

The process also awakes prematurely and becomes runnable if it receives a signal. This is used in situations where the process must wait without interruption or when the event is expected to occur quite quickly. The task's process descriptor must remain in case the parent wants to access it.

If the parent calls wait4 , the process descriptor is deallocated. This function sets the given task to the given state. If applicable, it also provides a memory barrier to force ordering on other processors this is only needed on SMP systems. Otherwise, it is equivalent to. Since the kernel data segment and user data segments both cover the full 4GB address space, then presumably it would be possible to access the process descriptor through the user data segment, if its address was known to user code.

Is this correct, and if so, is it not a security hole? A related question: there was an assertion that the linear address of the process descriptor can serve as a unique process ID. It does not map to anything in kernel address space. Secondly, if a process terminates, it is a zombie until the parent process "reaps" it via wait. The kernel must remember which processes are zombies i. For example, while a process with pid 37 may have had a task struct at address e. Stack Overflow for Teams — Collaborate and share knowledge with a private group.

Create a free Team What is Teams? Collectives on Stack Overflow. Learn more. Where is linux process descriptor stored and what can access it? Ask Question. Asked 5 years, 8 months ago. Normal program execution occurs in user-space. When a program executes a system call see Chapter 5 , "System Calls" or triggers an exception, it enters kernel-space. At this point, the kernel is said to be "executing on behalf of the process" and is in process context. When in process context, the current macro is valid [7].

Upon exiting the kernel, the process resumes execution in user-space, unless a higher-priority process has become runnable in the interim, in which case the scheduler is invoked to select the higher priority process.

There is no process tied to interrupt handlers and consequently no process context. System calls and exception handlers are well-defined interfaces into the kernel. A process can begin executing in kernel-space only through one of these interfaces all access to the kernel is through these interfaces.

A distinct hierarchy exists between processes in Unix systems, and Linux is no exception. All processes are descendents of the init process, whose PID is one. The kernel starts init in the last step of the boot process. The init process, in turn, reads the system initscripts and executes more programs, eventually completing the boot process. Every process on the system has exactly one parent. Likewise, every process has zero or more children. Processes that are all direct children of the same parent are called siblings.

The relationship between processes is stored in the process descriptor. Consequently, given the current process, it is possible to obtain the process descriptor of its parent with the following code:.