Hi! On 09:45 Fri 19 Dec , luca ellero wrote: > Michael Blizek wrote: >> Hi! > > Hi Michael and thank you for your reply. > >> On 14:35 Thu 18 Dec , luca ellero wrote: >>> 2. Why spin_lock_irqsave is used only between "IRQ Handler A" and >>> "IRQ Handler B"? In all other situation spin_lock_irq is used >>> instead. As far as I know you can use this function (spin_lock_irq) >>> only if you are absolutely sure interrupts are not already disabled. >>> So my question is how can we be absolutely sure in all this >>> situation that interrupts are not already disabled. >> >> There are 3 different ways you can handle interrupts when locking spinlocks: >> >> spin_lock: interrupts have to be *disabled* when calling this function > > Here I don't agree completely. Think about two timers trying to access > the same variable, I think spin_lock is sufficient without disabling > interrupts (in that situation the table is clear) The timer functions are always executed with interrupts disabled. >> spin_lock_irq: interrupts have to be *enabled* when calling this function and >> are disabled afterwards - After spin_unlock_irq, they are enabled. This is the >> case even if they were disabled before, which is probably not what you want. >> spin_lock_irqsave: may be called with interrupts enabled and disabled - The >> interrupt state is stored in a local "iflags" variable and is restored during >> spin_unlock_irqrestore. Use this, if you are not sure about the interrupt >> state. >> -Michi > > That's exactly what I mean, what is not clear for me is: > how can you be sure interrupts are not already disabled for whatever reason? Workqueue/thread functions, system call service routine start their execution with enabled interrupts. If their is a local_irq_disable, spin_lock_irq(save), lock_kernel or something similar, interrupts are disabled. If such a thing is not, interrupts are probably enabled. When you register a callback, usually there is a documentation whether your function is called with interrupts enabled or disabled. You can check it during runtime with (I think) in_interrupt() and maybe combine it with BUG_TRAP or WARN_ON. spin_locks are not the only case where interrupt state matters. When interrupts are disabled you cannot call sleep, wait_event and any long-running code causes the system to freeze in the mean time. > In other words, why the table doesn't use spin_lock_irqsave instead of > spin_lock_irq? I cannot tell you. You can always use spin_lock_irqsave. > Reading the table it seems that, for example, between "User Context A" > and "IRQ Handler A" using spin_lock_irq is sufficient. But how can you > be absolutely sure interrupts are enabled during execution of "User > Context A"? Couldn't they be already disabled for other reasons? When running in user context, interrupts are enabled, as long as nobody has disabled them. -Michi -- programing a layer 3+4 network protocol for mesh networks see http://michaelblizek.twilightparadox.com -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
