单核系统在中断服务程序中是不是不能使用spin_lock？

leslielg

如题，而应该使用禁止中断的spin_lock_irqxxx？

George_lz

leslielg 发表于 2012-08-22 13:36
如题，而应该使用禁止中断的spin_lock_irqxxx？

spin_lock 在UP系统中，所做的工作是禁止抢占。如果内核抢占都没开的话，基本上就是一个空函数，开抢占的时候，是禁止抢占。
        在UP中，如果不开抢占，只有进程时间片到，或主动让出CPU，才会进行调度。在开抢占的情况下，为了保护临界区数据在此次访问过程中，不被其他路径代码访问，此时，禁止抢占，就可以保护到临界区数据了。

spin_lock_irq***只是在spin_lock的功能基础上，禁止了中断而已。在2.6.34 以后的kernel中，已经禁止了中断嵌套，所以个人感觉，使用spin_lock也没有啥问题。

上面都是自己的理解，有不对的地方请指教！

omycle

回复 2# George_lz


   强烈赞同，呵呵

btw 1. 在UP的情况下，中断中不需要用spin_lock.
btw 2. 2.6.34之后，所有ARCH下的中断都不能嵌套？

George_lz

omycle 发表于 2012-08-22 17:21
回复 2# George_lz

根据代码提交意图，应该是针对所有的arch的，但这也与具体的使用有关。但具体是不是与具体的arch相关，也不敢肯定的这样说。由于我的开发环境是mips，以mips为例，在mips收到中断时，在保护现场时，disable mips 中断，然后就进入了plat 的irq dispatch，最后，进入了handle_irq，在handle_irq 里面进入driver所注册的handler。一般系统中断采用平出发，在2.6.34之前，在平触发的处理函数中，如果中断非独占，则会用（local_irq_enable_in_hardirq（））打开mips中断，这样就允许中断嵌套。
在2.6.34之后，只是去掉了（local_irq_enable_in_hardirq（）），一直不打开系统irq，直到irq执行结束。
kernel的平中断处理函数是系统通用代码，在这里修改，意图应该并不仅仅针对某个arch，应该是所有arch通用的。

此commit的描述如下：


commit e58aa3d2d0cc01ad8d6f7f640a0670433f794922
Author: Ingo Molnar <mingo@elte.hu>
Date:   Fri Mar 26 00:06:51 2010 +0000

    genirq: Run irq handlers with interrupts disabled
   
    Running interrupt handlers with interrupts enabled can cause stack
    overflows. That has been observed with multiqueue NICs delivering all
    their interrupts to a single core. We might band aid that somehow by
    checking the interrupt stacks, but the real safe fix is to run the irq
    handlers with interrupts disabled.
   
    Drivers for whacky hardware still can reenable them in the handler
    itself, if the need arises. (They do already due to lockdep)
   
    The risk of doing this is rather low:
   
   
     - lockdep already enforces this
     - CONFIG_NOHZ has shaken out the drivers which relied on jiffies updates
     - time keeping is not longer sensitive to the timer interrupt being delayed
   
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
    Cc: Andi Kleen <andi@firstfloor.org>
    Cc: David Miller <davem@davemloft.net>
    Cc: Greg Kroah-Hartman <gregkh@suse.de>
    Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
    Cc: Linus Torvalds <torvalds@osdl.org>
    LKML-Reference: <20100326000405.758579387@linutronix.de>

diff --git a/kernel/irq/handle.c b/kernel/irq/handle.c
index 76d5a67..27e5c69 100644
--- a/kernel/irq/handle.c
+++ b/kernel/irq/handle.c
@@ -370,9 +370,6 @@ irqreturn_t handle_IRQ_event(unsigned int irq, struct irqaction *action)
        irqreturn_t ret, retval = IRQ_NONE;
        unsigned int status = 0;

-       if (!(action->flags & IRQF_DISABLED))
-               local_irq_enable_in_hardirq();
-
        do {
                trace_irq_handler_entry(irq, action);
                ret = action->handler(irq, action->dev_id);

omycle

恩，在ARM中是允许不同中断嵌套的。所以看到你这么说我吓了一小跳呢。^_^

-----更正：Linux/ARM不允许中断嵌套。具体处理方式看12楼 ---

leslielg

如果可以中断嵌套，那么在中断中使用spin_lock就有问题了，如果这时不禁止中断（无论是否会禁止抢占，对中断没意义），spin_lock基本上就什么都没做，那这个spin_lock还能起到锁的作用么？
禁止中断嵌套的话那系统响应会受很大的影响吧？

leslielg

如果不允许中断嵌套，那中断处理函数里就不需要任何并发控制和考虑重入的问题了。这个很颠覆啊

George_lz

回复 5# omycle


    omycle兄，能不能帮忙讲一下arm进入到chip handle_irq这一块以前的操作，因为，以前在kernel 2.6. 30 左右的ChangeLog上，一直讨论着将中断嵌套的这一块处理去掉，所以一直想清楚mips之外arch的做法。
    mips本身也是支持中断嵌套的，但kernel上，从handle的处理上，就直接把这个feature给disable了。
    对于中断本身，再保护现场的过程中，禁止中断是必须的，但之后是否enable，个人感觉，可能还是应该在chip的handle里面做（不管具体是什么arch）。

George_lz

omycle 发表于 2012-08-22 23:01
恩，在ARM中是允许不同中断嵌套的（V3.3 Code）。所以看到你这么说我吓了一小跳呢。^_^

你说的这个允许嵌套，是哪里说明的？

leslielg

或者这样看，在software irq中，这时应该是没有禁止hardware irq的吧？使用spin_lock仍然不起任何作用，还是应该使用spin_lockirqxxx。不知想的对不对？