Michael Blizek ha wrote:
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
Thank you Michi, now it's a bit clearer
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
