1

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 ?

Rahul
  • 1,607
  • 3
  • 23
  • 41

2 Answers2

2

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.

Roland
  • 6,227
  • 23
  • 29
  • Could you please elaborate what happens when hardware requests handling when interrupts are disabled? – Basilevs Feb 07 '14 at 09:23
  • If hardware raises an interrupt while the CPU has interrupts disabled, then the interrupt will be pending until the CPU re-enables interrupts. When interrupts are reenabled, the CPU will take the interrupt and enter its ISR, but until then the CPU will simply ignore the pending interrupt. – Roland Feb 07 '14 at 09:34
0

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.

duck
  • 2,483
  • 1
  • 24
  • 34
  • I think you got confused. I asked if you are in process context and then interrupt comes what will happen if process context was holding a lock....and you explained me other way around. – Rahul Feb 07 '14 at 06:37
  • Doesnt matter if a process context is holding a lock it will just get rescheduled. This is what normally happens when a process context hold a lock – duck Feb 07 '14 at 06:40
  • It does'nt need interrupt to reschedule it, kernel will reshecdule it automatically for other processes unless it is using a spinlock – duck Feb 07 '14 at 06:41
  • so in that is the case what happen to the data protected by the lock, won't it be in inconsistent state ? And how can we overcome this .... – Rahul Feb 07 '14 at 06:43
  • You cant if the interrupt need the data hold by the process, it will have to wait to and thats a deadlock. This is exactly what i explained in answer – duck Feb 07 '14 at 06:44