Messages in this thread | | | From | Andrey Borzenkov <> | Subject | Re: when spin_lock_irq (as opposed to spin_lock_irqsave) is appropriate? | Date | Sat, 11 Oct 2008 19:55:13 +0400 |
| |
On Saturday 11 October 2008, Oliver Neukum wrote: > Am Samstag, 11. Oktober 2008 17:29:01 schrieb Andrey Borzenkov: > > Logically, one piece of kernel code has no way to know whether another > > piece of kernel code (or may be hard-/firmware) has disabled some > > interrupt line. So it looks like spin_lock_irq should not even exist, > > except may be for very specific cases (where we are sure no other piece > > of kernel code may run concurrently)? > > > > Sorry for stupid question, I an not actually a HW type of person ... > > > > This has no connection with individual irq lines. It's about being able > to sleep. Kernel code usually knows whether it can sleep. > If it knows to be able to sleep it can use spin_lock_irq() which is > more efficient than spin_lock_irqsave() >
Sorry? I can't sleep under spinlock ... *any* spinlock? Or has this changed?
May I be I was not clear with question. spin_lock_irq implies spin_unlock_irq, which unconditionally enables interrupts. But I have no idea which interrupts were disabled before spin_lock_irq; so I may accidentally enable too much?
Or what exactly "irq" in spin_(un-)lock_irq means?
TIA
-andrey [unhandled content-type:application/pgp-signature] | |