Linux内核中断处理程序互斥保护？

Question

我是否需要保护我的中断处理程序针对同一个中断被多次调用？

鉴于以下代码，我不确定我应该进行的系统调用。我在当前的实现中遇到了罕见的随机死锁:-

void interrupt_handler(void)
{
    down_interruptible(&sem);  // or use a lock here ?

    clear_intr(); // clear interrupt source on H/W

    wake_up_interruptible(...);

    up(&sem); // unlock?

    return IRQ_HANDLED;
}

void set/clear_intr()
{
    spin_lock_irq(&lock);
    RMW(x); // set/clear a bit by read/modify/write the H/W interrupt routing register
    spin_unlock_irq(&lock);
}

void read()
{
    set_intr();  // same as clear_intr, but sets a bit
    wait_event_interruptible(...);
}

1. interrupt_handler:down_interruptible 应该是 spin_lock_irq/spin_lock_irqsave/local_irq_disable?
2. set/clear_intr:spin_lock_irq 应该是 spin_lock_irqsave/local_irq_disable 吗？
3. 它(H/W -> kernel -> driver handler)能否继续生成/获取中断直到它被清除？ interrupt_handler 能否在其中继续被调用？
4. 如果当前实现的中断处理程序是可重入的，那么它会在 down_interruptible 上阻塞吗？

来自 LDD3:-

must be reentrant—it must be capable of running in more than one context at the same time.

---

编辑 1) 经过一些很好的帮助，建议是:-

1. 从 interrupt_handler 中删除 down_interruptible
2. 将 spin_lock_irq 移到 set/clear 方法之外(你说不需要 spin_lock_irqsave？)我真的看不出这样做有什么好处？!

代码:-

void interrupt_handler(void)
{
    read_reg(y); // eg of other stuff in the handler

    spin_lock_irq(&lock);

    clear_intr(); // clear interrupt source on H/W

    spin_unlock_irq(&lock);

    wake_up_interruptible(...);

    return IRQ_HANDLED;
}

void set/clear_intr()
{
    RMW(x);
}

void read()
{
    error_checks(); // eg of some other stuff in the read method

    spin_lock_irq(&lock);

    set_intr();  // same as clear_intr, but sets a bit

    spin_unlock_irq(&lock);

    wait_event_interruptible(...);

    // more code here...
}

---

Edit2) 阅读更多 SO 帖子后:阅读 Why kernel code/thread executing in interrupt context cannot sleep?链接到 Robert Loves article ，我读了这个:

some interrupt handlers (known in Linux as fast interrupt handlers) run with all interrupts on the local processor disabled. This is done to ensure that the interrupt handler runs without interruption, as quickly as possible. More so, all interrupt handlers run with their current interrupt line disabled on all processors. This ensures that two interrupt handlers for the same interrupt line do not run concurrently. It also prevents device driver writers from having to handle recursive interrupts, which complicate programming.

而且我启用了快速中断 (SA_INTERRUPT)!所以不需要 mutex/locks/semaphores/spins/waits/sleeps/等等!

Answer 1

不要在中断上下文中使用信号量，而是使用 spin_lock_irqsave。引用 LDD3:

If you have a spinlock that can be taken by code that runs in (hardware or software) interrupt context, you must use one of the forms of spin_lock that disables interrupts. Doing otherwise can deadlock the system, sooner or later. If you do not access your lock in a hardware interrupt handler, but you do via software interrupts (in code that runs out of a tasklet, for example, a topic covered in Chapter 7), you can use spin_lock_bh to safely avoid deadlocks while still allowing hardware interrupts to be serviced.

至于第 2 点，让您的 set_intr 和 clear_intr 要求调用者锁定自旋锁，否则您会发现代码死锁。同样来自 LDD3:

To make your locking work properly, you have to write some functions with the assumption that their caller has already acquired the relevant lock(s). Usually, only your internal, static functions can be written in this way; functions called from outside must handle locking explicitly. When you write internal functions that make assumptions about locking, do yourself (and anybody else who works with your code) a favor and document those assumptions explicitly. It can be very hard to come back months later and figure out whether you need to hold a lock to call a particular function or not.