lkml.org 
[lkml]   [2002]   [Jul]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Linux kernel deadlock caused by spinlock bug
From
Date
>  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/

\
 
 \ /
  Last update: 2005-03-22 13:22    [W:0.034 / U:1.896 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site