Deep understanding of Linux kernel spin lock __linux

Recently in the kernel frequently used spin lock, spin lock if used improperly, very easy to cause deadlock, in this summary.

A spin lock is a mutex device that has only two values: "Lock" and "unlock". It is usually implemented as a bit in an integer value. Want to get a bit related to a particular lock code test. If the lock is available, the lock is set, the code continues to enter the critical section; Conversely, if the lock is obtained by someone else, the code goes into a busy loop (rather than Hibernate, which is also the difference between a spin lock and a general lock) and checks the lock again until the lock is available, which is the spin process. The "Test and set bit" operation must be atomic so that only one thread can acquire the lock even if multiple threads spin at a given time.

Spin locks were originally designed to be used in multiprocessor systems (SMP), but as long as the concurrency problem is considered, a single processor behaves like SMP when it runs a preemption kernel. Therefore, spin locks apply to both SMP and single processor preemption cores. It can be imagined that when a processor is in the spin state, it does not do any useful work, so the spin lock for a single processor can not preempt the kernel meaningless, in fact, the non-preemptive single processor system spin lock is implemented as null operation, do nothing.

The spin lock has several important features: 1. The critical section code that is protected by a spin lock is not allowed to hibernate when executed. 2. The critical section code that is protected by spin lock cannot be interrupted by other interrupts. 3. The kernel cannot be preempted when the code of the critical section is protected by a spin lock. From these features can be summed up a common: the spin-lock protection of the critical section code execution, it can not be abandoned for any reason the processor.

Consider the first case above, imagine your kernel code requesting a spin lock and doing it in its critical section, somewhere in the middle where your code loses its processor. Perhaps it has called a function (Copy_from_user, suppose) to put the process into sleep. Or maybe the kernel grabs the edge, and a higher-priority process pushes your code aside. At this point, just some other thread is trying to get the same lock, if this thread is running on a different processor than your kernel code (fortunately), it may have to spin for a while (possibly a long time), and it will get locked when your code wakes up from hibernation or restarts the processor and releases the lock. And the worst case scenario is, the thread that wants to get the lock is just running with your code on the same processor, and it will always hold the CPU for spin, and your code is never going to have any chance to get the CPU to release the lock, which is a sad reminder of the deadlock.

Consider the second case above, similar to the first one. Suppose our driver is running and we have acquired a spin lock that controls access to the device. In the possession of this lock, the device produces an interrupt that causes the interrupt processing routine to be invoked, and the interrupt processing routine obtains the lock before accessing the device. When the interrupt processing routine and our driver code are running on the same processor, our code will not get a chance to release the lock because the interrupt handling routine holds the CPU spinning, which will also lead to deadlock.

Therefore, if we have a spin lock that can be obtained by code that runs in the context of the interrupt (hardware or software), you must disable the local interrupt by using a lock that disables the interrupt (note that the interrupt for the local CPU is disabled and no other processor interrupts are disabled), Spin_lock The use of other locking functions will sooner or later result in system deadlock (the time of deadlock may be uncertain, but the probability of this deadlock is certainly there, see how the Processor scheduling). If we do not access the spin lock in a hard interrupt handler routine, but may access it in a soft interrupt (for example, code that runs as Tasklet), you should use SPIN_LOCK_BH to safely avoid deadlocks while still servicing hardware outages.

Add:

There are four functions to lock a spin lock:

void Spin_lock (spinlock_t *lock);

The most basic spin lock function, it does not fail the local interrupt.

void Spin_lock_irqsave (spinlock_t *lock, unsigned long flags);

Disable hard interrupts (on the local processor only) prior to obtaining the spin lock, while the previous interrupt state is saved in flags

void Spin_lockirq (spinlock_t *lock);

Disable hard interrupts (on the local processor only) before obtaining a spin lock without saving the interrupt state

void Spin_lock_bh (spinlock_t *lock);

Disable soft interrupts before obtaining a lock, keeping the hard interrupt open