Messages in this thread | | | Date | Tue, 30 Jul 2002 10:44:57 -0700 | From | William Lee Irwin III <> | Subject | Re: [Linux-ia64] Linux kernel deadlock caused by spinlock bug |
| |
On Tue, Jul 30, 2002 at 12:06:54PM -0500, Van Maren, Kevin wrote: > It isn't obvious to me how to extend those queued to reader/writer > locks if you have to allow recursive readers without incurring the > same overhead of tracking which processors already have a reader lock. > If you do want to trigger recursive rw_locks, simply change the header > file to make them normal spinlocks. Then whenever the kernel hangs, > see where it is. Of course, this approach only finds all of them if > you execute every code path. > Does anyone want to chip in on why we need recursive r/w locks? Or why it > is hard to remove them? It doesn't sound like they are used much.
The tasklist_lock is taken in interrupt context by sigio generation, and read_locks on it are permitted to be interrupted by other read_locks, where write_locks of it must mask interrupts locally to prevent deadlock. I think IA64 performance monitor code does it in interrupt context too.
Older (2.4.x and 2.5.x-early) took the tasklist_lock in interrupt context to compute the load average by traversing the list of all tasks. My concern when I changed that was largely timeslice overrun.
Cheers, Bill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |