Can ISRs migrate to other processors when they are unloaded?

Question

In older versions of the Linux kernel, interrupt processing (ISR) procedures for hardware IRQs in the SMP system were run on the processor where they started, from start to finish. If it was unloaded by any other code, the ISR will subsequently resume on the same CPU.

But in recent kernels, most ISRs should run in the context of special kernel threads by default ( http://lwn.net/Articles/433854/ ). "Normal" core threads can be transferred to another CPU during crowding out. So the question is, can ISRs also do such things now, for any reason?

Please note that I'm not talking about the proximity of the processor to the IRQ and balancing the IRQ between the processors. I am wondering when the interrupt handler is already running but unloaded.

That is, suppose that the ISR has already started execution on CPU # 1. Now it is unloaded with some higher priority code. When the latter has completed its work, ISR resumes execution, but on CPU # 2. Are such situations possible?

Pointers to relevant documents, discussions, etc. always welcome.

Answer 1

ISR flows have the same proximity as ISR procedures, so in the case of preemption, the ISR stream does not transfer to an arbitrary processor.

, ISR . threadirqs. ISR , ISR . kernel/irq/manage.c, preemption :

/*
 * Interrupts which are not explicitely requested as threaded
 * interrupts rely on the implicit bh/preempt disable of the hard irq
 * context. So we need to disable bh here to avoid deadlocks and other
 * side effects.
 */
static void
irq_forced_thread_fn(struct irq_desc *desc, struct irqaction *action)
{
        local_bh_disable();
        action->thread_fn(action->irq, action->dev_id);
        irq_finalize_oneshot(desc, action, false);
        local_bh_enable();
}