Concurrency and Memory Diagnostics

What is it?

The debugging tools that catch concurrency and memory bugs while the kernel runs: stack guard pages, heap canaries, a lock-order validator, a soft-lockup watchdog, data-race and address sanitisers, a lock browser and one memory statistics file. Two of these exist in other forms (guard pages on the main kernel stack of each process, and heap cookies with redzones); the validators, sanitisers, watchdog and browsers are not built, and every row of this roadmap's table is still open.

How does it work?

Kernel stack guard pages. task_create() in task.c allocates each kernel stack of TASK_STACK_SIZE (8 KiB) plus one page, and turns the lowest page into a guard with vmm_install_guard_page() and the label GUARD: kernel task stack overflow. If the guard cannot be installed the task is refused rather than run unguarded, and user thread kernel stacks get the same treatment. Three creation paths do not: task_create_user() and task_fork() give the new process a kernel stack from kmalloc(), and so does kthread_create() for kernel threads, so an overflow there corrupts the heap instead of faulting. A guard is also only enforced under page tables that saw it: vmm_create_user_pml4() copies the kernel's page directory by value, so a guard installed after a process was created is not present under that process's CR3 (Per-Process User Page Mapping). Where the guard is present, an overflow faults on it, and the page-fault handler prints the label from vmm_guard_page_label() (vmm.h). The guard table holds VMM_MAX_GUARD_PAGES (640) entries, sized for TASK_MAX (32) tasks with up to THREAD_MAX (16) threads each plus headroom.

Heap corruption checks. Every kmalloc() block in heap.c carries a header cookie, a front redzone and an 8-byte back redzone. They are checked on free and realloc; a mismatch poisons the heap and bugchecks with BUGCHECK_IOS_HEAP_CORRUPTION, reporting whether the front or back redzone was hit. This is always on, not a debug build option, and it covers the general heap only; there is no SLAB allocator for it to cover yet (see Kernel Heap and Allocators).

Preemption counter. Each CPU's struct per_cpu_data has a preempt_count field (smp.h), zeroed at CPU bring-up. No API increments it yet.

Memory statistics. NtQuerySystemInformation(SystemPerformanceInformation) in nt_syscall.c returns three page counts (available, used and total frames from the frame allocator) and requires SeSystemProfilePrivilege from a user-mode caller.

What are its interfaces?

Interface	Purpose
`vmm_install_guard_page()`, `vmm_uninstall_guard_page()`, `vmm_guard_page_label()`, `vmm_guard_pages_free()`	Labelled guard pages (`vmm.h`)
`kmalloc()`, `kfree()`	Cookie and redzone checking on every block (`heap.h`)
`per_cpu_data.preempt_count`	Per-CPU preemption nesting field, not yet driven
`NtQuerySystemInformation` class 2	Available, used and total page counts

How do I use it?

An overflow of a guarded kernel stack, or heap corruption, shows up on the serial log and the panic screen with its label or fault class; there is nothing to enable. Guard page installation, saturation and refusal paths are tested in test_vmm.c, and redzone exact fit in test_heap.c:

bash scripts/test.sh SUITE=mm

What is not implemented yet?

Guards on every stack. Guards ship under different names on the task_create() and user-thread paths, but user processes created by task_create_user(), forked tasks and kernel threads still run on unguarded kmalloc() stacks, and a guard installed after a process root was cloned is not enforced under it (Thread Stack Guard Pages).
Preemption debugging. No preempt_disable(), depth limit or preemptible() check (Preemption Count -- Debug Extensions).
SLAB red zones and a free-time canary (Heap Canaries + SLAB Red Zones).
Lockdep for lock-order validation (Lock Dependency Validator).
A soft-lockup watchdog thread. The ACPI hardware watchdog in Boot Watchdog is a different feature (Kernel Watchdog Thread).
KCSAN and KASAN (KCSAN, KASAN).
A graphical deadlock view and /sys/locks (Graphical Deadlock Visualisation, Named Lock Browser).
/sys/mem, one memory statistics file for Win32 and Linux-style readers (/sys/mem Unified Memory Observability).

How does it compare with Windows 11 and Linux?

Windows 11 has stack guards, Driver Verifier special pool and deadlock detection, a watchdog bugcheck and KASAN in test builds; Linux has CONFIG_SLUB_DEBUG, lockdep, the lockup detector, KCSAN, KASAN and /proc/meminfo. Linux also guards kernel stacks in production through CONFIG_VMAP_STACK. Impossible OS has stack guards on most kernel stacks and always-on heap redzones, which Linux enables only with SLUB debugging, but none of the validators or sanitisers. The two planned additions neither ships are a framebuffer graph of a deadlock cycle and a unified /sys/mem.