Hi Jisheng, On Fri, Oct 28, 2016 at 9:49 AM, Jisheng Zhang <jszhang@xxxxxxxxxxx> wrote: > This is not the key. The key here is: > > compared with the non-irq version, the irq-version spin lock does one extra > work: disable the local interrupts. But since we are in interrupt handler, > the local irq is already disabled, so there's no need for the irq-versions. > > I'm not sure I understand the situation, comments are welcome. Quoting http://www.xml.com/ldd/chapter/book/ch09.html: "Many users of spinlocks stick to spin_lock and spin_unlock. If you are using spinlocks in interrupt handlers, however, you must use the IRQ-disabling versions (usually spin_lock_irqsave and spin_unlock_irqsave) in the noninterrupt code. To do otherwise is to invite a deadlock situation. It is worth considering an example here. Assume that your driver is running in its read method, and it obtains a lock with spin_lock. While the read method is holding the lock, your device interrupts, and your interrupt handler is executed on the same processor. If it attempts to use the same lock, it will go into a busy-wait loop, since your read method already holds the lock. But, since the interrupt routine has preempted that method, the lock will never be released and the processor deadlocks, which is probably not what you wanted. This problem can be avoided by using spin_lock_irqsave to disable interrupts on the local processor while the lock is held. When in doubt, use the _irqsave versions of the primitives and you will not need to worry about deadlocks. Remember, though, that the flags value from spin_lock_irqsave must not be passed to other functions." And as I mentioned before Documentation/locking/spinlocks.txt is very clear about the need of using spin_lock_irqsave inside interrupt handlers. Feel free to submit a patch to Documentation/locking/spinlocks.txt if you think this is incorrect. Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
