What is the Linux Kernel Task Structure?

When you run any program on a Linux system — a web browser, a shell script, a background daemon, or even a kernel thread — the kernel needs a place to keep track of everything about that running entity. It needs to know the program’s current state (is it sleeping? running? stopped?), which CPU it is on, which files it has open, what its memory layout looks like, its user credentials, its signal handlers, and dozens of other details.

The Linux kernel solves this by defining a large C structure called struct task_struct. This structure is the complete representation of a task. In Linux kernel terminology, both processes and threads are called tasks. Each task — whether it is a user-space process, a user-space thread, or a kernel thread — gets exactly one task_struct instance allocated in kernel memory.

Think of struct task_struct as the “identity card + passport + medical record + property deed” of a running task, all bundled into one. Everything the kernel needs to know about a task is either directly stored in task_struct or accessible through pointers hanging off it.

Where is struct task_struct Defined in the Linux Kernel?

The task structure is defined in the kernel header file include/linux/sched.h. This is one of the most important and most included headers in the entire Linux kernel source tree. Almost every subsystem of the kernel — scheduling, memory management, virtual file system, networking, security — ends up pulling in this header because almost every subsystem needs to work with tasks.

On a modern kernel (6.x series), the task_struct is enormous — well over 700 members. Its size on a 64-bit x86 system can exceed 10,000 bytes. This reflects just how much information the kernel needs to maintain per task to support preemptive multitasking, security isolation, resource accounting, and all the other services a modern OS provides.

You can explore it yourself on your system:

# Find where task_struct is defined
$ grep -n "struct task_struct {" /usr/src/linux-headers-$(uname -r)/include/linux/sched.h

# Count the number of members (approximate)
$ grep -c ";" /usr/src/linux-headers-$(uname -r)/include/linux/sched.h

Key Members of the Linux Task Structure

Rather than going through every single field (which would take a book), let’s focus on the members that matter most for anyone studying Linux kernel programming or Linux device drivers development. We group them by category.

3.1 Task State

The __state member (older kernels used state) tracks what the task is currently doing. This is a bitmask field. The most common states are:

In a kernel module, you can read the state of any task whose task_struct pointer you have. For example:

#include <linux/sched.h>

/* Assume 'task' is a valid struct task_struct pointer */
if (task_is_running(task))
    pr_info("Task %s is currently runnable\n", task->comm);

3.2 PID, TGID, and How Linux Identifies Tasks

Every task in Linux has two important numeric identifiers stored in task_struct:

• pid (Process ID): Uniquely identifies this specific task (thread) in the kernel. Each thread gets its own unique PID at the kernel level.
• tgid (Thread Group ID): All threads belonging to the same process share the same TGID. This is what getpid() returns in user space — the TGID of the thread group leader.

This distinction is why the output of ps -eLf shows more entries than ps -ef: the former shows kernel-level PIDs (one per thread), while the latter shows user-visible PIDs (which are actually TGIDs).

# Show all threads with their kernel-level PID (LWP column)
$ ps -eLf | head -20

# See all threads of a specific process
$ ps -eLf | grep myapp

3.3 Task Name (comm)

The comm member stores the name of the task as a short character array. On modern kernels this is 16 bytes (including the null terminator), so task names are limited to 15 characters. This is the name you see in the output of tools like top, htop, and /proc/<pid>/comm.

/* Print the name of the current task from a kernel module */
#include <linux/sched.h>
#include <linux/kernel.h>

pr_info("Current task name: %s\n", current->comm);
pr_info("Current task PID:  %d\n", current->pid);
pr_info("Current task TGID: %d\n", current->tgid);

3.4 Memory Management: mm_struct

Each task has a pointer called mm that points to a struct mm_struct. This structure describes the virtual address space of the process — where the code segment is, where the stack is, the heap, memory-mapped regions, and the page table root. Threads within the same process share the same mm_struct, which is how they share virtual memory.

There is also an active_mm pointer. For regular user processes, mm and active_mm point to the same structure. For kernel threads, mm is NULL (kernel threads have no user-space virtual address space), but active_mm temporarily borrows the mm of the most recently scheduled user process. This “lazy TLB” trick avoids expensive TLB flushes when the kernel thread does not actually access user memory.

3.5 Credentials and Capabilities

Security in Linux is built around the concept of task credentials. The cred member in task_struct points to a struct cred that stores:

• UID, GID (real and effective)
• Supplementary group list
• Linux capability sets (permitted, effective, inheritable, bounding, ambient)
• Security labels (used by SELinux, AppArmor)

The credential structure uses Copy-On-Write (COW) semantics. A task’s credentials can be replaced atomically using commit_creds(), which is how su, sudo, and setuid programs elevate privileges safely.

3.6 Open Files (files_struct)

The files member points to a struct files_struct, which maintains the table of open file descriptors for the task. File descriptors 0, 1, and 2 (stdin, stdout, stderr) are entries in this table. When a process opens a file, a new file descriptor entry is added here. When threads are created, they typically share the same files_struct, which is why threads within a process see the same file descriptors.

3.7 CPU Scheduling Information

The task structure contains several scheduling-related fields. The most important ones for a kernel programming student to know are:

The Task List: How the Kernel Organizes All task_struct Objects

At any given moment, a busy Linux system may have thousands of tasks active simultaneously. The kernel needs to organize all these task_struct objects so they can be found and iterated efficiently. It achieves this using an intrusive circular doubly linked list called the task list.

The task_struct contains a member of type struct list_head named tasks. This embeds the linked list node directly inside the task structure — this is the “intrusive” linked list pattern that is extremely common throughout the Linux kernel. All task structures are chained together through their tasks member, forming a ring.

The kernel provides a convenient macro for_each_process(p) to iterate over all processes in this list. Under the hood it uses list_for_each_entry() starting from the global init_task (the idle process, PID 0).

#include <linux/sched/signal.h>
#include <linux/init_task.h>

struct task_struct *task;

/* Iterate over all processes (thread group leaders only) */
for_each_process(task) {
    pr_info("Process: %-16s  PID: %d  State: %ld\n",
            task->comm, task->pid, task_state_index(task));
}

/* To iterate over ALL tasks including threads, use: */
/* for_each_process_thread(p, t) { ... } */

What Gets Inherited Across fork() — and What Does Not

When a process calls fork() (or when a thread is created via pthread_create(), which internally calls clone()), a new task_struct is allocated for the child. The kernel copies most fields from the parent’s task structure to the child’s, but a number of fields are reset or treated differently. Understanding this is important for anyone studying Linux kernel development or device drivers.

Common Mistakes When Working with task_struct in Kernel Modules