Skip to main content

4.3 Exercises and Reflections

If you've made it this far, the mechanisms should be clear—or so you might think. This section is where we put theory to the real test. The exercises below increase in difficulty. We recommend thinking through them independently before checking the hints, and only referring to the hints if you get stuck.

If some of these exercises feel a bit "sadistic," don't worry—that's intentional. Driver development is a hands-on craft; reading API documentation alone will never help you write your first working driver.

Exercise 4.1: Observing Timer Interrupts​

Task: On an x86 system (a virtual machine is fine), verify the following phenomenon: although the count for the traditional timer interrupt (IRQ 0) remains unchanged, there is actually another periodic system interrupt continuously incrementing to maintain the time base for each CPU core.

Hint: Recall the proc pseudo-file we looked at in the previous section. What you're looking for is right there.

Exercise 4.2: Writing a Keylogger Driver (Advanced Hands-on)​

⚠️ Warning: Ethical Hacking Only This exercise is strictly limited to security learning on your own systems. Recording keystrokes on unauthorized systems is illegal. Additionally, this exercise relies on x86-specific hardware (the i8042 controller) and typically does not work properly in virtual machines.

Task: Write a simple kernel keylogger driver using the kernel's misc framework. By hooking into the i8042's IRQ 1 (keyboard interrupt), "capture" keyboard press and release events and read the key scancodes.

Implementation Steps:

  1. Data Buffering: Use the kfifo data structure in kernel space to temporarily store these scancodes.
  2. User Space Interaction: Write a user-space process (or thread) that periodically reads data from your driver's kfifo into a user-space buffer and writes it to a log file.
  3. Decoding: Write an application (or use another thread) to interpret these scancodes and translate them into readable characters.

Practical Tips:

  • Architecture Constraints: How do we ensure this driver only compiles on x86? Add #ifdef CONFIG_X86 at the very beginning of the code.
  • Virtual Machine Detection: How do we ensure it only runs on physical machines? We can use the virt-what tool in the driver loading script and refuse to execute insmod if it's not a physical machine.
  • A Better Approach: Frankly, using a driver to write a keylogger is both difficult and unnecessary (unless you're writing a virus or rootkit, which is a different story entirely). Usually, querying the kernel's input subsystem event layer from the application layer via evtest(1) is much simpler and safer. The sole purpose of this exercise is to give you hands-on experience handling hardware interrupts and kernel buffers.

Reference Materials:

  • Kernel kfifo example: samples/kfifo/bytestream-example.c
  • US keyboard scancode mapping table: Philip Storr's PC book or the OSDev Wiki.

Exercise 4.3: Fill in the Blank — Deferral Mechanisms​

The kernel provides a mechanism known as "deferral functionality," commonly referred to as __________. They are designed to achieve the best of both worlds:

  1. __________________
  2. __________________

A. Top Half; run the hardirq as fast as possible; immediately restore the interrupted context afterward. B. Bottom Half; allow driver authors to perform longer interrupt processing when needed, in a deferred and safe manner, while keeping the system's normal work running. C. Better Half; do more work in interrupt context to avoid paying the cost later. D. Bottom Half; run interrupt code with interrupts disabled and let it run for a long time.

Exercise 4.4: Finding Tasklets​

Task: Using a code browsing tool (we recommend cscope(1) or ctags), find drivers in the kernel source tree that use the tasklet_hi_schedule() API.

Reflection: Why do these drivers use high-priority tasklets? What special types of tasks are they handling?

Exercise 4.5: Ftrace Latency Measurement​

Task: Use Ftrace's irqsoff latency tracer plugin to find the longest interrupt disabled time in the system.

Step-by-Step Guide:

  1. Kernel Configuration: You need to enable CONFIG_IRQSOFF_TRACER. If it's not enabled by default, look for it under make menuconfig in Kernel hacking -> Tracers.
  2. Compile and Reboot: Don't forget to make and reboot.
  3. Lockdep: When performing this kind of measurement, we recommend disabling Lockdep to prevent its own overhead from skewing the results.
  4. Analysis: Observe the output in /sys/kernel/debug/tracing/trace.

Reference Material: Steven Rostedt's paper Finding Origins of Latencies Using Ftrace.

Chapter Recap and Summary​

We covered a lot of ground in this chapter.

Starting from the original hardware signal—that single wire pulling high a CPU pin—we saw how the kernel wraps it in the complex abstraction layer of the irq_desc array to hand you a clean irqreturn_t function. We discussed why doing all the work directly in a hardirq is suicidal behavior (interrupt starvation), which led us to the philosophy of Top Halves / Bottom Halves.

We learned how to use modern APIs like devm_request_threaded_irq to let the kernel automatically clean up the battlefield for us, and we saw how hybrid mechanisms like NAPI can save the day during network floods.

Remember the question at the beginning of this chapter about "why does the device not respond even though driver registration succeeded?" You should be able to answer it now: successful registration only means the kernel has claimed the device. But if the IRQ line isn't properly bound, or if the interrupt handler returns IRQ_NONE, the device's cries go unheard. The interrupt system is a second heartbeat alongside the kernel's own—it must be timely and deterministic, yet not so domineering that it drags the entire system down.

This is really an art of "compromise." Between speed and responsiveness, between hardware reality and software ideals, the interrupt subsystem finds a delicate balancing path.

In the next chapter, we'll turn our attention to another common asynchronous mechanism in the kernel: workqueues. Unlike softirqs and tasklets, they run in process context. What does that mean? It means they can finally "sleep" in peace.

Further Reading and Resources​

If this chapter didn't melt your brain enough, or if you want to see some debates about the future, the links below are worth bookmarking.

Core Documentation​

In-Depth Topics​

Interrupt Trigger Modes:

  • Edge Triggered versus Level Triggered interrupts (2013)
  • Level-triggered versus Edge-triggered Interrupts (2008)

NAPI and Softirq Frontiers:

  • Threadable NAPI polling, softirqs, and proper fixes (Jon Corbet, 2016): Discusses the combination of NAPI and threading.
  • Per-vector software-interrupt masking (Jon Corbet, 2019): On the future direction of fine-grained softirq vector masking.

IRQ Affinity and Performance:

  • IRQ Balancing (ntop project)
  • Setting interrupt affinity systems (RHEL8 docs)

Debugging and Analysis Tools​

Modern eBPF Toolchain:

  • Linux bcc/eBPF tracing tools (Brendan Gregg): A modern toolset for performance analysis using eBPF.

In-Depth Ftrace Guides:

  • ftrace – Function Tracer (Kernel Doc)
  • Debugging the kernel using ftrace (Steven Rostedt, LWN 2009)
  • Secrets of the ftrace function tracer (Steven Rostedt, LWN 2010)
  • trace-cmd: a frontend for ftrace (Steven Rostedt, LWN 2010)

Exercises​

Exercise 1: understanding​

Question: In Linux driver development, what is the fundamental difference in resource management between the traditional request_irq() and the modern recommended devm_request_threaded_irq()? Please explain in the context of "managed resources."

Answer and Analysis

Answer: request_irq() is the traditional registration method, requiring the driver author to explicitly call free_irq() when unloading the module or removing the device to free interrupt resources; otherwise, it leads to resource leaks. devm_request_threaded_irq(), on the other hand, is the "managed" version. It leverages the driver core's managed resource mechanism to automatically release the allocated IRQ upon device detach, eliminating the need for manual cleanup code, thereby preventing resource leaks and simplifying the code.

Analysis: This question tests your understanding of kernel API evolution. Modern Linux kernel driver development introduced the concept of 'managed resources' (devm_* interfaces) to reduce human error by automatically managing resource lifecycles. Understanding this helps in writing more robust and concise driver code.

Exercise 2: application​

Question: Suppose you are writing a driver for a high-speed network card that supports interrupt sharing. When calling request_irq(), how should you set the flags parameter to ensure system stability and comply with shared interrupt conventions, and what must you do before returning from the interrupt handler?

Answer and Analysis

Answer: When calling request_irq(), you must include the IRQF_SHARED flag via a bitwise OR in the flags parameter. Additionally, as a shared interrupt handler, you must check the hardware status registers inside the function to determine whether the interrupt was actually triggered by your device; if not, you must return IRQ_NONE and never misidentify it.

Analysis: This is an application question testing practical coding standards. 1. Shared interrupts must declare IRQF_SHARED, otherwise registration will fail. 2. A shared IRQ line means multiple devices share the same physical signal. When the CPU responds to an interrupt, the kernel iterates through all registered handlers on that line. If a handler cannot correctly identify non-device interrupts and return IRQ_NONE, it will cause an "interrupt storm" or erroneous device operations.

Exercise 3: understanding​

Question: In a network device driver, an interrupt is triggered when a data packet is received. Considering that the interrupt handler runs in "atomic context," if you need to allocate a 1KB buffer in the driver to store the packet data at this point, should you use kmalloc() or kmalloc(GFP_ATOMIC)? Why?

Answer and Analysis

Answer: You should use kmalloc(GFP_ATOMIC) (or a similar variant with the __GFP_ATOMIC flag).

Analysis: This question tests your understanding of "interrupt context" constraints. The standard kmalloc() uses the GFP_KERNEL flag by default, which allows the memory allocator to put the current process to sleep to wait for page reclaim when memory is low. However, interrupt handlers run outside of non-atomic process context (hardirq context) and cannot sleep. Using the GFP_ATOMIC flag tells the allocator to attempt an immediate allocation; if it fails, it must immediately return NULL and must never let the calling path enter a sleeping state.

Exercise 4: thinking​

Question: Suppose the interrupt handler you wrote is scheduled by the system as a "threaded interrupt." If you execute an operation that triggers a sleep (such as calling msleep() or waiting on a mutex) within the handler thread, is this allowed? Please explain the mechanism in the context of the IRQF_ONESHOT flag.

Answer and Analysis

Answer: Yes, it is allowed. The core purpose of threaded interrupts is to move heavy or blocking operations from hardirqs into a kernel thread. Kernel threads have their own process context, so they can safely sleep. The role of the IRQF_ONESHOT flag is to ensure that the hardware IRQ line remains masked until the threaded handler completes, preventing the interrupt from triggering infinitely again before processing is finished and the hardware interrupt source is cleared, which would cause an interrupt storm.

Analysis: This question involves deep thinking about the modern interrupt handling model (Threaded IRQ). Traditional hardirqs require fast, non-blocking execution. After Linux introduced the threaded irq model, handling is split into two parts: the Primary handler (hardirq part, which only does minimal processing) and the Threaded handler (kernel thread part). IRQF_ONESHOT is a key flag that works with threaded interrupts; it guarantees that even if the thread is handling time-consuming or blocking operations, the underlying IRQ signal won't be re-enabled too early, thereby avoiding the problem of level-triggered interrupts repeatedly re-entering before processing is complete. Understanding this helps in reasonably splitting tasks in driver design, balancing system response speed with data processing throughput.

Key Takeaways​

The Linux kernel shields hardware differences like x86's IO-APIC or ARM's GIC through the generic IRQ handling layer. Driver development only requires calling request_irq() or its modern managed version devm_request_irq()即可将中断处理函数挂载到内核的维护的 IRQ 链表中。注册时必须提供正确的标志位（如共享中断的 `IRQF_SHARED`）和用于区分设备的 `dev_id`，处理函数被调用时处于不可睡眠的原子上下文，必须快速完成状态确认并返回 `` IRQ_HANDLED. Calling any kernel function that might block or trigger scheduling is strictly prohibited.

To resolve the contradiction between hardirqs "executing fast but unable to sleep" and complex device processing "taking a long time and potentially blocking," modern Linux drivers widely adopt the Threaded IRQ model. Through the request_threaded_irq() API, developers can split interrupt logic into two parts: the Primary Handler, running in atomic context, performs only the most urgent hardware acknowledgments, while the woken kernel thread possesses full process context and can safely hold mutexes, access sleepable memory, or execute time-consuming data transfer tasks.

In high-throughput scenarios (such as 10G network cards), relying solely on interrupts causes the CPU to fall into a "livelock" state of handling massive interrupt context switches. Therefore, network drivers introduce the NAPI (New API) hybrid mechanism. After receiving the first packet triggers an interrupt, NAPI temporarily disables the device's hardirq and switches to polling mode, using softirqs to process this batch of data centrally, and re-enables interrupts only after the buffer is cleared, thereby striking a balance between low latency and high throughput.

In addition to moving heavy work to dedicated threads, the kernel provides softirq and tasklet mechanisms for deferred execution. Softirqs are a statically compiled, high-performance mechanism commonly used for network transmit/receive, but they can preempt user processes when running extensively; Tasklets are built on top of softirqs, providing a more friendly dynamic interface and guaranteeing that the same tasklet will not execute concurrently on multiple CPUs. This simplifies concurrency control in driver development and is suitable for most non-network general-purpose driver scenarios.

When debugging interrupt issues, developers should make full use of kernel-provided tools for verification. The /proc/interrupts file can display the trigger count and owning device for each IRQ on each CPU core in real time; a count of 0 indicates the hardware signal is not connected. Meanwhile, kernel macros in_irq() and might_sleep() can help check context legality at the code level, preventing the erroneous use of blocking functions that are only allowed in process context within interrupt handlers.