Messages in this thread | | | Date | Mon, 1 Mar 1999 14:12:33 -0800 (PST) | From | Linus Torvalds <> | Subject | Re: [patch] syslog fix? 2.2.2 |
| |
On Mon, 1 Mar 1999, Ingo Molnar wrote: > > this one looks like a place that relies on the 'old' behavior of > sleep_on*? We go into interruptible_sleep_on() with interrupts disabled, > and if sleep_on() write-locks on waitqueue_lock, another CPU read-locks > waitqueue_lock and is interrupted, then that IRQ or bh deadlocks, boom.
If you write-lock on waitqueue-lock, then you will release the lock and try again. A write lock will never wait with the lock held, so the other CPU should not read-lock. See the write_lock(rw) implementation:
asm volatile("\n1:\t" \ "lock ; btsl $31,%0\n\t" \ "jc 4f\n" \ "2:\ttestl $0x7fffffff,%0\n\t" \ "jne 3f\n" \ ".section .text.lock,\"ax\"\n" \ "3:\tlock ; btrl $31,%0\n" \ "4:\tcmp $0,%0\n\t" \ "jne 4b\n\t" \ "jmp 1b\n" \ ".previous" \ :"=m" (__dummy_lock(&(rw)->lock)))
Note how we release the lock at label 3.
> this also means that it's completely illegal to do sleep_on* with > interrupts disabled ... have i missed something?
I think you just overlooked the basic writelock implementation.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |