Development of a Resource Locking Algorithm for a Kernel Debugging User-space API Library TJHSST Computer Systems Lab Timothy Wismer

Introduction: Kernel-space and User-space ● The Linux Kernel provides the core functionality of a system—interaction with hardware, management of file systems, etc. ● All other programs depend on the functionality provided by the kernel, and are said to exist in user-space. ● Because of the critical position of the kernel, development and testing is very difficult. ● This project aims to simplify kernel development by moving kernel functionality to user-space.

Operating System Layers Hardware Layer (ex: Matrox Millenium II Graphics Card) Hardware Layer (ex: matroxfb_base.o driver) Abstraction Layer (ex: framebuffer) User-space (ex: OpenGL Library) Kernel-space Functionality to be ported by KDUAL

Introduction: Resource Locking ● Access to resources used by multiple processes must be atomic to avoid problems. ● Atomicity means that the entire operation succeeds or fails as a whole, and creates no intermediate state visible to other processes. ● A series of operations is made atomic by restricting those operations with a single, inherently atomic operation—the lock. ● As long as all processes use the lock to access the resource, they should not conflict.

Introduction: Deadlock ● Deadlock occurs when a process tries to obtain a resource that will not be available until the process gives up a resource that it already holds. ● Deadlock can involve any number of processors. ● Deadlock cannot resolve on its own—unless interrupted by some outside entity, it will cause the system to lock up. ● The KDUAL locking implementation will include deadlock detection.

Theory: Detection of Deadlock ● When processes are waiting on held locks, they depend on the process that holds the lock. If A depends on B and B depends on C, A also depends (indirectly) on C. ● Deadlock occurs when a process depends on itself (through any number of intermediaries). ● In a graph with nodes representing processes and edges representing dependencies, a deadlock will appear as a cycle: a complete path from a node back to itself.

A Deadlock Scenario 2 1,3 3 2 Each box represents a lock, held by the process identified in the oval. The inner box identifies processes waiting for the lock: Processes 2 and 3 each want the lock held by the other; process 1 is not part of the deadlock.

Wait-For Graph The WFG representation of the previous slide. The cycle clearly shows a deadly embrace involving processes 2 and 3:

The Deadlock Detection Algorithm ● A separate Deadlock Detection Thread (DDT) will be created when the application starts. ● The locking functions will make information about process dependencies available to the DDT. ● The DDT will periodically check the dependency information for WFG cycles to identify deadlocks. ● In the event that a deadlock is detected, one involved process will be terminated and the user will be provided with debugging information.

Future Development & Value to Others ● Completion of KDUAL – so far the locking implementation is the only component; much more would be needed to make KDUAL usable. ● A working KDUAL would simplify and speed up development of kernel code. ● Apart from KDUAL, the locking implementation can serve as a “test suite” for applications that use locking.