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

Question

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 acq

Answer 1

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.