Re: [Linux-ia64] Linux kernel deadlock caused by spinlock bug

[Richard B. Johnson]

On Tue, 30 Jul 2002, Russell Lewis wrote:

> Richard B. Johnson wrote:
> 
> >On Tue, 30 Jul 2002, Russell Lewis wrote:
> >
> >You need to gain a lock just to read the bias field. You can't read
> >something that somebody else will change while you are deciding
> >upon what you read. It just can't work.
> >
> I intentionally made bias a non-precise field.  It really doesn't matter 
> if it gets corrupted; it is just a rough idea of what's going on.  So 
> there's no problem reading it without a lock.  If the value you read is 
> wrong (or partial), then the worst that happends is bunch of NOPs before 
> you try for the lock (an undesirable, but not disastrous occurance).
> 
> >If we presume that it did work. What problem are you attempting
> >to fix?  FYI, there are no known 'lock-hogs'. Unlike a wait on
> >a semaphore, where a task waiting will sleep (give up the CPU), a
> >deadlock on a spin-lock isn't possible. A task will eventually
> >get the resource. Because of the well-known phenomena of "locality",
> >every possible 'attack' on the spin-lock variable will become
> >ordered and the code waiting on the locked resource will get
> >it in a first-come-first-served basis. This, of course, assumes
> >that the code isn't broken by attempts to change the natural
> >order.
> >
> Check out the title of the thread...  Somebody has a real, reproducible 
> deadlock on a rw_lock where many readers are starving out a writer, and 
> the system hangs.
> 

They have, as you say, "real reproducible" deadlocks because they are
not using straight spin-locks. Sombody tried to use cute queued locks.
This invention is the cause of the problem. The solution is to not
try to play tricks on "Mother Nature".

Cheers,
Dick Johnson
Penguin : Linux version 2.4.18 on an i686 machine (797.90 BogoMips).
The US military has given us many words, FUBAR, SNAFU, now ENRON.
Yes, top management were graduates of West Point and Annapolis.