Have you ever wondered how your computer knows what to do when you press enter on your keyboard or plug in a USB drive? These are two common examples of handling hardware interrupts, a key mechanism for the Linux kernel in almost every interaction between internal processes and communication between external devices. This article will explore how interrupts are handled in the Linux operating system—starting with what they are and the role they serve.
What are interrupts?
Interrupts are events that pause running programs to execute other tasks. There are hardware interrupts and software interrupts—sent either from hardware devices or from certain processes running in the operating system. The programmable interrupt controller (PIC) requests an interrupt request (IRQ) to the CPU and executes the interrupt service routine (ISR). The current process is then interrupted until the ISR is complete.
The interrupt handler in the kernel executes several ISRs. The ISR handles the request event (a hardware or software interrupt), then sends it to the CPU, pausing the active process. When the ISR is complete, the CPU will resume the process. Interrupt handling is the most complicated task controlled by the Linux kernel. Various problems can arise when handling interrupts:
- Interrupts can occur at any time, commonly known as asynchronous interrupts.
- The Linux kernel might need to handle a new interrupt when it’s handling a previous one. The kernel will use the first in, first out (FIFO) approach when this occurs.
- When multiple interrupts occur continuously, the kernel must disable vital parts to prevent serious problems, such as abortion errors (failures in hardware devices like CPU or RAM) or system crashes resulting from software errors or I/O problems).
The primary role of interrupts
Operating systems rely on signals for communication with hardware devices or between processes. This is where interrupts come in: An interrupt is simply the signal that lets the operating system know what actions it should take to ensure that the system can communicate with the outside world or its internal processes.
Types of interrupts
A Linux kernel needs to handle three kinds of interrupts: software interrupts, hardware interrupts, and exceptions.
Software interrupts allow different processes running in the system to interact with each other. Let’s say there is an application with a feature to delete all caching data from the browser. When the application attempts to delete the caching data, some data will still be used by the browser.
An interrupt will block the application from deleting caching data in cases like this. Software interrupts are a fundamental feature of computing and a part of the built-in core process that is executed when a computer boots up.
Devices use hardware interrupts to interact with the CPU. If the CPU is available, it suspends the current thread and executes the interrupt handling job for the device. For example, system administrators need to type in an authentication token to log into the production server and update the user table in a MySQL database.
The token is retrieved from a token device that system administrators often carry. Before the token input, the system administrator will only view the login screen. After they enter the authentication token, the system verifies it and the system administrator can then access the server to update the user table. Thanks to the kernel handling the hardware interrupt, the production server can immediately verify whether or not the token input is valid.
Types of hardware interrupts
Hardware interrupts can be split into two types:
- Can be delayed, disabled, or ignored according to its priority
- Used with peripheral devices
- Can be vectored or non-vectored
- Required for immediate action when it occurs
- Used in emergencies, for instance power outages
- Can only be vectored
When the CPU executes a command that leads to failure, additional execution is interrupted. If this occurs, an alert window will pop-up or a stack trace error log will display in the console output.
There are three types of exceptions:
- Faults: These are non-critical errors and the process can resume normally once they are resolved.
- Aborts: These are serious errors that keep the system from continuing certain processes, resulting from problems such as physical damage to RAM or CPU or incorrect system configuration.
How does the kernel handle hardware interrupts?
The interrupt is a high priority task, and the kernel must also handle it as fast as possible so that other running processes won't have to wait for too long. This is why the Linux kernel handles hardware interrupts in two steps: First it executes the process most critical for replying to the interrupt, followed by the less urgent one.
Can hardware interrupts be avoided?
Hardware interrupts enable the hardware device to interact with the operating system. At times, however, hardware interrupts might cause serious problems for the production server. For example, the server might be running heavy counting tasks for a big data application.
In this scenario, hardware interrupts can halt the process, preventing it from resuming. Fortunately, there are ways to avoid hardware interrupts.
Maskable interrupts can be turned on or off by modifying their flag configuration. For example, with the x86 assembly, the hardware interrupts can be disabled by setting the interrupt flag value to 0.
Devices can also be disabled to stop them from connecting to the production server. For instance, to disable connecting devices via USB in Ubuntu distro, run the following command line:
chmod 700 /usr/lib/gvfs/gvfsd-mtp
chmod 700 /usr/lib/gvfs/gvfsd-afc
Unfortunately, only maskable interrupts can be disabled to avoid hardware interrupts; non-maskable interrupts cannot be avoided.
Handling hardware interrupts is one of the Linux kernel’s most important jobs. Understanding how Linux handles hardware interrupts will make work easier and troubleshooting quicker. Moreover, critical problems can be prevented, such as high CPU usage, crashing applications, or even data loss.
Was this article helpful?
Sorry to hear that. Let us know how we can improve the article.