From: Rusty Russell <rusty@rustcorp.com.au>
To: Ingo Molnar <mingo@elte.hu>
Cc: Mike Travis <travis@sgi.com>, Dieter Ries <clip2@gmx.de>,
linux-kernel@vger.kernel.org
Subject: Re: 2.6.29-rc1 does not boot
Date: Thu, 15 Jan 2009 11:24:21 +1030 [thread overview]
Message-ID: <200901151124.22442.rusty@rustcorp.com.au> (raw)
In-Reply-To: <20090112100053.GA7905@elte.hu>
On Monday 12 January 2009 20:30:53 Ingo Molnar wrote:
> work_on_cpu() seems
> completely unsuited for any sort of set_cpus_allowed() replacement ...
That's harsh. set_cpus_allowed is *always* questionable in these cases. Sometimes it's harmless, and sometimes there was a risk that we could run on the wrong cpu.
The mistake was that work_on_cpu() should rely on the caller to ensure the CPU doesn't go away. It's a worse interface, but this reduces the number of *new* bugs, at least.
Subject: cpumask: don't try to get_online_cpus() in work_on_cpu.
This has caused more problems than it solved, with a pile of cpu
hotplug locking issues.
Followup patches will get_online_cpus() in callers that need it, but
if they don't do it they're no worse than before when they were using
set_cpus_allowed without locking.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -991,8 +991,7 @@ static void do_work_for_cpu(struct work_
* @fn: the function to run
* @arg: the function arg
*
- * This will return -EINVAL in the cpu is not online, or the return value
- * of @fn otherwise.
+ * It is up to the caller to ensure that the cpu doesn't go offline.
*/
long work_on_cpu(unsigned int cpu, long (*fn)(void *), void *arg)
{
@@ -1001,14 +1000,12 @@ long work_on_cpu(unsigned int cpu, long
INIT_WORK(&wfc.work, do_work_for_cpu);
wfc.fn = fn;
wfc.arg = arg;
- get_online_cpus();
if (unlikely(!cpu_online(cpu)))
wfc.ret = -EINVAL;
else {
schedule_work_on(cpu, &wfc.work);
flush_work(&wfc.work);
}
- put_online_cpus();
return wfc.ret;
}
next prev parent reply other threads:[~2009-01-15 0:54 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-11 14:55 2.6.29-rc1 does not boot Dieter Ries
2009-01-11 15:19 ` Ingo Molnar
2009-01-11 15:30 ` Dieter Ries
2009-01-11 15:35 ` Ingo Molnar
2009-01-11 15:41 ` Dieter Ries
2009-01-11 18:50 ` Dieter Ries
2009-01-11 19:02 ` Mike Travis
2009-01-11 19:30 ` Dieter Ries
2009-01-12 10:00 ` Ingo Molnar
2009-01-12 17:53 ` Mike Travis
2009-01-12 18:55 ` Ingo Molnar
2009-01-15 0:54 ` Rusty Russell [this message]
2009-01-11 19:02 ` Ingo Molnar
2009-01-11 19:14 ` Mike Travis
2009-01-11 23:19 ` Mike Travis
2009-01-12 1:01 ` H. Peter Anvin
2009-01-12 11:22 ` Maciej Rutecki
2009-01-12 11:26 ` Ingo Molnar
2009-01-12 11:28 ` Maciej Rutecki
2009-01-12 12:10 ` Dieter Ries
2009-01-12 12:21 ` Ingo Molnar
2009-01-12 16:37 ` Dieter Ries
2009-01-12 18:59 ` Ingo Molnar
2009-01-13 4:45 ` Michal Jaegermann
2009-01-12 17:22 ` 2.6.29-rc1 does not boot and fails to resume Rafael J. Wysocki
2009-01-14 1:16 ` 2.6.29-rc1 does not boot Rusty Russell
2009-01-14 11:30 ` Ingo Molnar
2009-01-14 12:47 ` Dieter Ries
2009-01-15 20:01 ` Mike Travis
2009-01-15 21:03 ` Dieter Ries
2009-01-15 21:48 ` Maciej Rutecki
2009-01-15 21:54 ` Mike Travis
2009-01-15 23:04 ` Maciej Rutecki
2009-01-15 23:31 ` Mike Travis
2009-01-15 21:54 ` Mike Travis
2009-01-15 23:02 ` Dieter Ries
2009-01-15 23:30 ` Mike Travis
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=200901151124.22442.rusty@rustcorp.com.au \
--to=rusty@rustcorp.com.au \
--cc=clip2@gmx.de \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=travis@sgi.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.