Messages in this thread |  | | Subject | Re: Linux kernel deadlock caused by spinlock bug | From | john stultz <> | Date | 29 Jul 2002 14:55:24 -0700 |
| |
> I have hit a problem with the Linux reader/writer spinlock > implementation that is causing a kernel deadlock (technically > livelock) which causes the system to hang (hard) when running > certain user applications. This problem could be exploited as > a DoS attack on medium-to-large SMP machines. <snip> > With "several" processors acquiring and releasing read locks, it is > possible for a processor to _never_ succeed in acquiring a write lock. > Even though the read lock is held for a very short period, with much > contention for the cache line the processor would often lose ownership > before it could release the read lock. [Even if it had it longer, > because it was looping, there would still be a good chance that it > would lose the cache line while holding the reader lock.] By the time > the reader got the cache line back to release the lock, another processor > had acquired the read lock. This behavior resulted in a processor not > being able to acquire the write lock, which it was attempting to do in > an interrupt handler. So the interrupt handler was _never_ able to > complete and other interrupts were blocked by that processor (in my > case, network and keyboard interrupts). > > The specific case I tracked down consisted of several processes in > a tight gettimeofday() loop, which resulted in the reader count never > getting to zero because there was always an outstanding reader. While > I will stipulate that it is not a good thing for several processes to > be looping in gettimeofday(), I will assert that it is a very bad thing > for a few processes calling such a benign system call to hang the system.
I just wanted to add a "me too" on this. I'm also seeing rw-lock starvation in do_gettimeofday(). While it does not lead to system deadlock, it does cause the values returned from gettimeofday to loop as the timer_bh cannot increment the xtime values (causing possible application deadlock). In my case,the problem is exaggerated because I'm using do_slowgettimeofffset due to TSC skew on the i386 hardware I'm using.
thanks -john
- 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/
|  |