From: Russell Lewis <spamhole-2001-07-16@deming-os.org>
To: root@chaos.analogic.com
Cc: linux-kernel@vger.kernel.org
Subject: Re: [Linux-ia64] Linux kernel deadlock caused by spinlock bug
Date: Tue, 30 Jul 2002 10:02:35 -0700 [thread overview]
Message-ID: <3D46C6AB.1000103@deming-os.org> (raw)
In-Reply-To: Pine.LNX.3.95.1020730124325.5378A-100000@chaos.analogic.com
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.
next prev parent reply other threads:[~2002-07-30 17:01 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-07-29 21:05 [Linux-ia64] Linux kernel deadlock caused by spinlock bug Van Maren, Kevin
2002-07-29 21:18 ` Matthew Wilcox
2002-07-30 15:58 ` Russell Lewis
2002-07-30 16:56 ` Richard B. Johnson
2002-07-30 17:02 ` Russell Lewis [this message]
2002-07-30 17:14 ` Richard B. Johnson
2002-07-30 22:48 ` Sean Griffin
2002-07-31 17:37 ` Russell Lewis
-- strict thread matches above, loose matches on Subject: below --
2002-07-30 21:15 Van Maren, Kevin
2002-07-30 17:06 Van Maren, Kevin
2002-07-30 17:44 ` William Lee Irwin III
[not found] <3FAD1088D4556046AEC48D80B47B478C0101F3AE@usslc-exch-4.slc.unisys.com.suse.lists.linux.kernel>
2002-07-30 13:32 ` Andi Kleen
2002-07-30 16:27 ` William Lee Irwin III
2002-07-29 21:29 Van Maren, Kevin
2002-07-29 21:48 ` David Mosberger
2002-07-29 20:37 Van Maren, Kevin
2002-07-29 20:46 ` [Linux-ia64] " Matthew Wilcox
2002-07-29 20:37 Van Maren, Kevin
2002-07-29 20:46 ` Matthew Wilcox
2002-07-29 21:05 ` Van Maren, Kevin
2002-07-29 21:18 ` Matthew Wilcox
2002-07-29 21:29 ` Van Maren, Kevin
2002-07-29 21:48 ` David Mosberger
2002-07-30 15:58 ` Russell Lewis
2002-07-30 16:56 ` Richard B. Johnson
2002-07-30 22:48 ` Sean Griffin
2002-07-31 17:37 ` Russell Lewis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3D46C6AB.1000103@deming-os.org \
--to=spamhole-2001-07-16@deming-os.org \
--cc=linux-kernel@vger.kernel.org \
--cc=root@chaos.analogic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.