2002-07-29 21:25:07

by Van Maren, Kevin

[permalink] [raw]
Subject: RE: [Linux-ia64] Linux kernel deadlock caused by spinlock bug

> On Mon, Jul 29, 2002 at 04:05:35PM -0500, Van Maren, Kevin wrote:
> > Recursive read locks certainly make it more difficult to fix the
> > problem. Placing a band-aid on gettimeofday will fix the symptom
> > in one location, but will not fix the general problem, which is
> > writer starvation with heavy read lock load. The only way to fix
> > that is to make writer locks fair or to eliminate them (make them
> > _all_ stateless).
>
> The basic principle is that if you see contention on a spinlock, you
> should eliminate the spinlock somehow. making spinlocks
> `fair' doesn't
> help that you're spending lots of time spinning on a lock.

Yes, but that isn't the point: unless you eliminate all rw locks,
it is conceptually possible to cause a kernel deadlock by forcing
contention on the locks you didn't remove, if the user can force
the kernel to acquire a reader lock and if something else needs to
acquire the writer lock. Correctness is the issue, not performance.
You have locks because there _could_ be contention, and locks handle
that contention _correctly_. If you can eliminate the contention,
you can eliminate the locks, but if there is a chance for contention,
the locks have to remain, _and_ they have to handle contention
_correctly_, which does not occur with the current reader/writer
lock code, which can hang the kernel just as dead as a writer
between recursive reader lock calls with my code.

Kevin


2002-07-29 21:45:25

by David Mosberger

[permalink] [raw]
Subject: RE: [Linux-ia64] Linux kernel deadlock caused by spinlock bug

>>>>> On Mon, 29 Jul 2002 16:29:09 -0500, "Van Maren, Kevin" <[email protected]> said:

Van> Yes, but that isn't the point: unless you eliminate all rw
Van> locks, it is conceptually possible to cause a kernel deadlock
Van> by forcing contention on the locks you didn't remove, if the
Van> user can force the kernel to acquire a reader lock and if
Van> something else needs to acquire the writer lock. Correctness
Van> is the issue, not performance.

I agree with Kevin here. There must be some argument as to why
readers cannot indefinitely lock out a writer. A probabilistic
argument is fine, but just saying "contention doesn't happen"
certainly isn't good enough.

--david