1. What Is Process Context in the Linux Kernel?

When you write a Linux kernel module or a Linux device driver, your code does not run in a vacuum. Every line of kernel code executes in some context. The most common context is called process context.

In simple terms: when a user-space process (like your terminal, a browser, or a script) makes a system call — such as read(), write(), or open() — the CPU switches from user mode into kernel mode. While in kernel mode, the kernel code that executes is said to be running in process context because it is the user process itself that triggered the execution.

This is a very important idea to internalize if you are serious about Linux kernel development.

The key takeaway: in process context, the kernel code knows which process triggered it. You can ask the kernel “who is running right now?” — and it will give you a meaningful, valid answer. This is not always true in other execution contexts (like interrupt context, which we discuss below).

2. The current Macro — Your Window Into the Running Task

The Linux kernel maintains a data structure for every process and thread alive on the system. This structure is called task_struct. It holds everything the kernel knows about a process — its PID, name, credentials, memory maps, open files, scheduling info, and much more.

Inside kernel code (your module, your driver), you can access the task_struct of the currently executing process using the special macro:

/* Defined in: include/linux/sched.h */
current   /* pointer to the task_struct of the currently running process/thread */

This macro is one of the most frequently used building blocks in Linux kernel programming. It gives you a pointer to the task_struct of whoever is “on the CPU” right now, in the current kernel context.

Key Fields Inside task_struct You Should Know

Reading Process Info in a Kernel Module — A Clean Example

Here is how you safely read the current process’s info inside a kernel module’s init function. This is original code — do not confuse it with any particular book’s sample. The logic is standard kernel module practice:

#include <linux/init.h>
#include <linux/module.h>
#include <linux/kernel.h>
#include <linux/sched.h>     /* task_struct, current */
#include <linux/cred.h>      /* current_uid(), current_euid() */

MODULE_LICENSE("GPL");
MODULE_AUTHOR("EmbeddedPathashala");
MODULE_DESCRIPTION("Demonstrate process context using the current macro");

static int __init procctx_init(void)
{
    /* 'current' gives a pointer to the task_struct
     * of the process that ran insmod */
    pr_info("=== Process Context Demo ===\n");
    pr_info("Process Name : %s\n", current->comm);
    pr_info("PID          : %d\n", task_pid_nr(current));
    pr_info("TGID         : %d\n", task_tgid_nr(current));
    pr_info("UID          : %u\n", from_kuid(&init_user_ns,
                                    current_uid()));
    pr_info("EUID         : %u\n", from_kuid(&init_user_ns,
                                    current_euid()));

    /* Print kernel stack start address securely */
    pr_info("Kernel Stack : %pK\n", current->stack);

    return 0;
}

static void __exit procctx_exit(void)
{
    pr_info("Process Name at rmmod: %s\n", current->comm);
    pr_info("=== Process Context Demo: exit ===\n");
}

module_init(procctx_init);
module_exit(procctx_exit);

When you insert this module with sudo insmod procctx.ko, the init function runs. And the key observation: current->comm will print insmod — because it is literally the insmod process that is executing the init function inside kernel mode. When you remove it with sudo rmmod procctx, the exit function runs in the context of the rmmod process.

3. Why the Linux Kernel Is Called Monolithic — And What That Actually Means

One of the classic exam questions in Linux kernel development courses is: “Is Linux a monolithic kernel or a microkernel?” The answer is: Linux is a monolithic kernel. But what does that really mean, and why does the process context demo above prove it?

Monolithic vs Microkernel — A Clear Comparison

In a monolithic kernel like Linux, when the insmod utility inserts a kernel module, it issues a system call (finit_module() or init_module()). The CPU switches to kernel mode. The kernel loads the module and calls its init function — all in the context of the insmod process itself. There is no separate “kernel daemon” executing that code. The insmod process IS the executor.

This is why when you check current->comm inside a module’s init function, you see “insmod” — and inside the exit function (called via rmmod), you see “rmmod”. This is monolithic kernel behaviour in action.

Process Context vs Interrupt Context — Side by Side

As a Linux device driver developer, you will constantly need to know what context you are in. Many kernel APIs — like kmalloc(..., GFP_KERNEL) or mutex_lock() — can only be called from process context because they may sleep. Calling them from interrupt context will cause a kernel panic or BUG.

4. Printing Kernel Addresses Securely — The %pK Format Specifier

When you are writing a Linux kernel module or driver, you sometimes need to print a memory address for debugging. A naive approach using %p or %lx can leak kernel virtual addresses to unprivileged users through dmesg. This is a real security vulnerability called a kernel information leak.

The Linux kernel provides a safer format specifier called %pK that respects the system’s pointer restriction settings.

Understanding Kernel Pointer Format Specifiers

Secure Address Printing in a Kernel Module

#include <linux/kernel.h>
#include <linux/sched.h>

/* GOOD — Uses %pK which respects kptr_restrict */
pr_info("task_struct address : %pK\n", current);
pr_info("kernel stack start  : %pK\n", current->stack);

/* BAD — Leaks actual address to unprivileged users in dmesg */
/* pr_info("task_struct : %px\n", current);  -- AVOID in production */

/* For debugging only — contrast the two */
pr_debug("Actual addr (debug): %px | Secure: %pK\n",
          current, current);

Kernel Security Tunables — kptr_restrict and dmesg_restrict

The behaviour of %pK is controlled by a kernel sysctl parameter. You should always configure this on production embedded Linux systems:

# Check current kptr_restrict setting
cat /proc/sys/kernel/kptr_restrict

# Set to 1: hides addresses from users without CAP_SYSLOG
sudo sysctl -w kernel.kptr_restrict=1

# Set to 2: hides addresses from ALL users including root (most secure)
sudo sysctl -w kernel.kptr_restrict=2

# Also restrict dmesg to privileged users only
sudo sysctl -w kernel.dmesg_restrict=1

# Make permanent — add to /etc/sysctl.d/99-security.conf:
# kernel.kptr_restrict = 1
# kernel.dmesg_restrict = 1

5. Real-World Application — Why This Matters for Driver and Embedded Developers

If you are learning Linux kernel development or working on a free Linux device drivers course, understanding process context is not optional — it is foundational. Here are concrete scenarios where this knowledge directly applies:

6. Common Mistakes Beginners Make in Linux Kernel Development

• ❌ Calling sleeping functions from interrupt context — causes a kernel BUG or lockdep warning. Always check context before using kmalloc(GFP_KERNEL) or mutex_lock().
• ❌ Using %px in production printk calls — leaks kernel addresses. Use %pK always.
• ❌ Trusting current in interrupt context — it might point to whatever process happened to be on the CPU when the interrupt fired. It is not meaningful.
• ❌ Directly accessing current->state — use task_is_running() or check __state on newer kernels. Direct field access may break across kernel versions.
• ❌ Not checking return values of insmod — if your module’s init returns an error, insmod silently fails. Always check dmesg immediately after insertion.
• ❌ Forgetting MODULE_LICENSE("GPL") — without this, your module will taint the kernel and some GPL-only symbols become inaccessible.

Frequently Asked Questions — Process Context and Linux Kernel

Conclusion

Understanding process context in the Linux kernel is one of the most important foundational concepts you need before you can write correct, production-quality kernel modules and device drivers. We covered how a user process drives kernel module execution via system calls, why Linux is described as a monolithic (yet modular) kernel, how the current macro gives you access to the running task’s task_struct, and how to print kernel addresses securely using %pK with proper sysctl hardening.

In the next lecture, we build on this foundation and explore how the Linux kernel maintains a task list — a linked list of every process and thread on the system — and how you can write a kernel module to iterate over it and inspect every running task. This is the kind of knowledge that underpins process managers, debuggers, security tools, and system monitoring drivers in real embedded Linux products.

If you are following this free Linux kernel development course on EmbeddedPathashala, make sure you build and test the demo module on your own system. Reading is not enough — the real learning happens when you see “insmod” printed by your own kernel module.