From: Robert Love <rml@tech9.net>
To: mingo@elte.hu
Cc: Linus Torvalds <torvalds@transmeta.com>,
linux-kernel@vger.kernel.org, Mike Kravetz <kravetz@us.ibm.com>,
Anton Blanchard <anton@samba.org>,
george anzinger <george@mvista.com>,
Davide Libenzi <davidel@xmailserver.org>,
Rusty Russell <rusty@rustcorp.com.au>
Subject: Re: [patch] O(1) scheduler, -G1, 2.5.2-pre10, 2.4.17 (fwd)
Date: 10 Jan 2002 15:01:22 -0500 [thread overview]
Message-ID: <1010692888.5338.319.camel@phantasy> (raw)
In-Reply-To: <Pine.LNX.4.33.0201101457390.4885-100000@localhost.localdomain>
In-Reply-To: <Pine.LNX.4.33.0201101457390.4885-100000@localhost.localdomain>
On Thu, 2002-01-10 at 09:19, Ingo Molnar wrote:
> - Kevin O'Connor, Robert Love: fix locking order bug in set_cpus_allowed()
> which bug is able to cause boot-time lockups on SMP systems.
Along the same lines as the above, note this code snippet from
try_to_wake_up:
lock_task_rq(rq, p, flags);
p->state = TASK_RUNNING;
if (!p->array) {
if (0 && !rt_task(p) && synchronous && (smp_processor_id() < p->cpu)) {
spin_lock(&this_rq()->lock);
p->cpu = smp_processor_id();
activate_task(p, this_rq());
spin_unlock(&this_rq()->lock);
} else { ... }
First, H1 added the 0 there ... ???
Second, prior to the change, I wonder whether the
(smp_processor_id() < p->cpu)) is inverted. We've already locked p's
runqueue above. So this branch, if taken, will lock the current
runqueue -- but it checks if current's cpu id is _less_ then p's! Thus
we lock greater to lesser. Would a proper change be:
diff -urN linux-2.5.2-pre10-H1/kernel/sched.c linux/kernel/sched.c
--- linux-2.5.2-pre10-H1/kernel/sched.c Thu Jan 10 14:56:06 2002
+++ linux/kernel/sched.c Thu Jan 10 14:56:21 2002
@@ -383,7 +383,7 @@
lock_task_rq(rq, p, flags);
p->state = TASK_RUNNING;
if (!p->array) {
- if (0 && !rt_task(p) && synchronous && (smp_processor_id() < p->cpu)) {
+ if (!rt_task(p) && synchronous && (smp_processor_id() > p->cpu)) {
spin_lock(&this_rq()->lock);
p->cpu = smp_processor_id();
activate_task(p, this_rq());
Note I removed the 0, which may or not be your intention (do you want
that code branch there at all?) My point is swapping the
lesser-than-sign for a greater-than so that we now lock this_rq only if
it is _greater_ than p's.
Keep 'em coming ;)
Robert Love
next prev parent reply other threads:[~2002-01-10 19:59 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-01-10 14:19 [patch] O(1) scheduler, -G1, 2.5.2-pre10, 2.4.17 (fwd) Ingo Molnar
2002-01-10 18:20 ` Linus Torvalds
2002-01-10 20:11 ` george anzinger
2002-01-10 23:54 ` Ingo Molnar
2002-01-10 23:22 ` Ingo Molnar
2002-01-11 0:01 ` Ingo Molnar
2002-01-10 20:01 ` Robert Love [this message]
2002-01-10 23:44 ` Ingo Molnar
2002-01-10 21:57 ` Mike Kravetz
2002-01-11 0:48 ` Ingo Molnar
2002-01-10 23:04 ` Davide Libenzi
2002-01-11 21:42 ` François Cami
2002-01-11 21:46 ` Timothy Covell
[not found] ` <1010814327.2018.5.camel@phantasy>
2002-01-12 11:48 ` François Cami
2002-01-12 16:26 ` Timothy Covell
2002-01-12 20:00 ` Robert Love
2002-01-12 20:44 ` Davide Libenzi
2002-01-12 20:44 ` Timothy Covell
2002-01-12 23:56 ` Robert Love
2002-01-13 6:59 ` Rusty Russell
2002-01-14 8:40 ` Marian Jancar
2002-01-11 21:53 ` Mark Hahn
-- strict thread matches above, loose matches on Subject: below --
2002-01-13 20:30 Dieter Nützel
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=1010692888.5338.319.camel@phantasy \
--to=rml@tech9.net \
--cc=anton@samba.org \
--cc=davidel@xmailserver.org \
--cc=george@mvista.com \
--cc=kravetz@us.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=torvalds@transmeta.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.