Linux Device Drivers

Race Conditions

Whenever a variable or other data item is modified at interrupt time, there is the possibility that the driver will operate inconsistently because of race conditions. A race condition happens whenever an operation is not executed atomically, but it still needs to count on data coherence throughout its execution. The ``race'' therefore is between the non-atomic operation and other code that might be executed in the meantime. Typically, race conditions appear in three situations: implicit calls to schedule from within a function, blocking operations, and access to data shared by interrupt code and system calls. The last situation is the most frequent, and that’s why race conditions are dealt with in this chapter.

Dealing with race conditions is one of the trickiest aspects of programming, because the related bugs are subtle and very difficult to reproduce, and it’s hard to tell when there is a race condition between interrupt code and the driver methods. The programmer must take great care to avoid corruption of data or metadata.

In general, the techniques used to prevent race conditions are implemented in the driver methods, which must be sure to handle the data items correctly if they unexpectedly change. The interrupt handler, on the other hand, doesn’t usually need special care, because it operates atomically with respect to the device methods.

Different techniques can be employed to prevent data corruption, and I’m going to introduce the most common ones. ...