How does Kernel handle the lock in process context when an interrupt comes?

1
votes

First of all sorry for a little bit ambiguity in Question... What I want to understand is the below scenario

Suppose porcess is running, it holds one lock, Now after acquiring the lock HW interrupt is generated, So How kernel will handle this situation, will it wait for lock ? if yes, what if the interrupt handler need to access that lock or the shared data protected by that lock in process ?

2
linux-kernelkernel

2 Answers

2
votes

The Linux kernel has a few functions for acquiring spinlocks, to deal with issues like the one you're raising here. In particular, there is spin_lock_irq(), which disables interrupts (on the CPU the process is running on) and acquires the spinlock. This can be used when the code knows interrupts are enabled before the spinlock is acquired; in case the function might be called in different contexts, there is also spin_lock_irqsave(), which stashes away the current state of interrupts before disabling them, so that they can be reenabled by spin_unlock_irqrestore().

In any case, if a lock is used in both process and interrupt context (which is a good and very common design if there is data that needs to be shared between the contexts), then process context must disable interrupts (locally on the CPU it's running on) when acquiring the spinlock to avoid deadlocks. In fact, lockdep ("CONFIG_PROVE_LOCKING") will verify this and warn if a spinlock is used in a way that is susceptible to the "interrupt while process context holds a lock" deadlock.

0
votes

Let me explain some basic properties of interrupt handler or bottom half.

  1. A handler can’t transfer data to or from user space, because it doesn’t execute in the context of a process.
  2. Handlers also cannot do anything that would sleep, such as calling wait_event, allocating memory with anything other than GFP_ATOMIC, or locking a semaphore
  3. handlers cannot call schedule.

What i am trying to say is that Interrupt handler runs in atomic context. They can not sleep as they cannot be rescheduled. interrupts do not have a backing process context

The above is by design. You can do whatever you want in code, just be prepared for the consequences

Let us assume that you acquire a lock in interrupt handler(bad design). When an interrupt occur the process saves its register on stack and start ISR. now after acquiring a lock you would be in a deadlock as their is no way ISR know what the process was doing.

The process will not be able to resume execution until it is done it with ISR

In a preemptive kernel the ISR and the process can be preempt but for a non-preemptive kernel you are dead.