Can an interrupt handler be unloaded by the same interrupt handler?

Question

Does the CPU block all interrupts on the local processor before calling the interrupt handler? Or does it just disable this particular interrupt line that is being served?

Answer 1

x86 disables all local interrupts (with the exception of NMI, of course) before moving on to the interrupt vector. Linux typically masks a particular interrupt and re-enables other interrupts (which are not masked), unless certain flags are passed to the interrupt handler registration.

Please note that although this means that your interrupt handler will not race with itself on the same CPU, it can and will race with itself, working on other processors in the SMP / SMT system.

Answer 2

Usually (at least on x86) an interrupt disables interrupts.

When an interrupt is received, the hardware performs the following actions:
1. Save all the registers in a specific location.
2. Set the instruction pointer (AKA program counter) to the address of the interrupt handler.
3. Set the register that controls interrupts to a value that disables all (or most) interrupts. This prevents another interrupt from being interrupted.

An exception is NMI (non-maskable interrupt), which cannot be disabled.

Answer 3

Yes it's good. I would also like to add what, in my opinion, can make a difference.

In many real kernel drivers / code, bottom-half (bh) handlers are used quite often - tasklets, softirqs. These bhs work in the context of interruption and can work in parallel with their upper half (th) handlers on SMP (esp softirq's).

Of course, recently in the direction of the main line (mainly, code transferred from the PREEMPT_RT project), there has been a transition to the main line, which significantly eliminates the "bh" mechanism - all interrupt handlers will work with all disabled interrupts. Moreover, handlers (can be) converted to kernel threads - these are the so-called "stream" interrupt handlers.

Today, the choice is still for the developer - you can use the “traditional” th / bh style or the threaded style.

Ref and details:

http://lwn.net/Articles/380931/

http://lwn.net/Articles/302043/

Answer 4

Composing quotes from our own surprisingly well-written Intel® 64 and IA-32 Software Developer's Guides, Volume 1, Pages 6-10:

If an interrupt or exception handler is called through the interrupt gate, the processor clears the interrupt enable flag (IF) in the EFLAGS register to prevent subsequent interruptions from interfering with the execution of the handler. When the handler is called through the gate hook, the state of the IF flag does not change.

So, just to be clear - yes, it is effective that the processor "disconnects" all interrupts before calling the interrupt handler. A properly described processor simply triggers a flag that causes it to ignore all interrupt requests. With the exception of probably not masked interrupts and / or its own software exceptions (please, someone will correct me, not checked ).

Answer 5

We want ISRs to be atomic and no one should preempt ISRs.

Therefore, the ISR disables local interrupts (i.e., an interrupt for the current processor), and as soon as the ISR calls the ret_from_intr () function (that is, we finished the ISR), the interrupts turn on again for the current processor.

If an interrupt occurs, it will be serviced by another processor (in the SMP system), and the ISR associated with this interrupt will start working.

In the SMP system, we also need to include the proper synchronization mechanism (direct blocking) in the ISR mechanism.