From: Andrew Morton <akpm@linux-foundation.org>
To: Rusty Russell <rusty@rustcorp.com.au>
Cc: Mike Travis <travis@sgi.com>, Ingo Molnar <mingo@redhat.com>,
Dave Jones <davej@redhat.com>,
cpufreq@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/3] work_on_cpu: Use our own workqueue.
Date: Wed, 28 Jan 2009 11:44:40 -0800 [thread overview]
Message-ID: <20090128114440.77abc1b2.akpm@linux-foundation.org> (raw)
In-Reply-To: <200901282332.29429.rusty@rustcorp.com.au>
On Wed, 28 Jan 2009 23:32:28 +1030 Rusty Russell <rusty@rustcorp.com.au> wrote:
> +static int do_work_on_cpu(void *unused)
> +{
> + for (;;) {
> + struct completion *done;
> +
> + wait_event(woc_wq, current_work != NULL);
> +
> + set_cpus_allowed_ptr(current, cpumask_of(current_work->cpu));
> + WARN_ON(smp_processor_id() != current_work->cpu);
> +
> + current_work->ret = current_work->fn(current_work->arg);
> + /* Make sure ret is set before we complete(). Paranoia. */
> + wmb();
> +
> + /* Reset current_work so we don't spin. */
> + done = ¤t_work->done;
> + current_work = NULL;
> +
> + /* Reset current_work for next work_on_cpu(). */
> + complete(done);
> + }
> +}
> +
> +/**
> + * work_on_cpu - run a function in user context on a particular cpu
> + * @cpu: the cpu to run on
> + * @fn: the function to run
> + * @arg: the function arg
> + *
> + * This will return the value @fn returns.
> + * 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)
> +{
> + struct work_for_cpu work;
> +
> + work.cpu = cpu;
> + work.fn = fn;
> + work.arg = arg;
> + init_completion(&work.done);
> +
> + mutex_lock(&woc_mutex);
> + /* Make sure all is in place before it sees fn set. */
> + wmb();
> + current_work = &work;
> + wake_up(&woc_wq);
> +
> + wait_for_completion(&work.done);
> + BUG_ON(current_work);
> + mutex_unlock(&woc_mutex);
> +
> + return work.ret;
> +}
We still have a queue - it's implicit now, rather than explicit.
It's vulnerable to the same deadlock, I think? Suppose we have:
- A lock, L
- A callback function which takes that lock, called function_which_takes_L()
- A task A which does work_on_cpu(function_which_takes_L)
- A task B which does
lock(L);
work_on_cpu(something_else);
Now,
- A calls work_on_cpu() and takes woc_mutex.
- Before function_which_takes_L() has started to execute, task B takes L
then calls work_on_cpu() and task B blocks on woc_mutex.
- Now function_which_takes_L() runs, and blocks on L
Nothing else happens...
next prev parent reply other threads:[~2009-01-28 19:48 UTC|newest]
Thread overview: 70+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-16 19:11 [PATCH 0/3] cpu freq: fix problems with work_on_cpu usage in acpi-cpufreq Mike Travis
2009-01-16 19:11 ` [PATCH 1/3] work_on_cpu: dont try to get_online_cpus() in work_on_cpu Mike Travis
2009-01-16 19:11 ` [PATCH 2/3] work_on_cpu: Use our own workqueue Mike Travis
2009-01-24 8:15 ` Andrew Morton
[not found] ` <200901261711.43943.rusty@rustcorp.com.au>
2009-01-26 7:01 ` Andrew Morton
2009-01-26 17:16 ` Ingo Molnar
2009-01-26 18:35 ` Andrew Morton
2009-01-26 20:20 ` Ingo Molnar
2009-01-26 20:43 ` Mike Travis
2009-01-26 21:00 ` Andrew Morton
2009-01-26 21:27 ` Ingo Molnar
2009-01-26 21:35 ` Andrew Morton
2009-01-26 21:45 ` Ingo Molnar
2009-01-26 22:01 ` Andrew Morton
2009-01-26 22:05 ` Ingo Molnar
2009-01-26 22:16 ` Andrew Morton
2009-01-26 22:20 ` Ingo Molnar
2009-01-26 22:50 ` Andrew Morton
2009-01-26 22:59 ` Ingo Molnar
2009-01-26 23:42 ` Andrew Morton
2009-01-26 23:53 ` Ingo Molnar
2009-01-27 0:42 ` Andrew Morton
2009-01-26 22:31 ` Oleg Nesterov
2009-01-26 22:15 ` Oleg Nesterov
2009-01-26 22:24 ` Ingo Molnar
2009-01-26 22:37 ` Oleg Nesterov
2009-01-26 22:42 ` Ingo Molnar
2009-01-26 21:50 ` Oleg Nesterov
2009-01-26 22:17 ` Ingo Molnar
2009-01-26 23:01 ` Mike Travis
2009-01-27 0:09 ` Oleg Nesterov
2009-01-27 7:15 ` Rusty Russell
2009-01-27 17:55 ` Oleg Nesterov
2009-01-27 7:05 ` Rusty Russell
2009-01-27 7:25 ` Andrew Morton
2009-01-27 15:28 ` Ingo Molnar
2009-01-27 16:51 ` Andrew Morton
2009-01-28 13:02 ` Rusty Russell
2009-01-28 17:19 ` Mike Travis
2009-01-28 17:32 ` Mike Travis
2009-01-29 10:39 ` Rusty Russell
2009-01-28 19:44 ` Andrew Morton [this message]
2009-01-29 1:43 ` Rusty Russell
2009-01-29 2:12 ` Andrew Morton
2009-01-30 6:03 ` Rusty Russell
2009-01-30 6:30 ` Andrew Morton
2009-01-30 13:49 ` Ingo Molnar
2009-01-30 17:08 ` Andrew Morton
2009-01-30 21:59 ` Rusty Russell
2009-01-30 22:17 ` Andrew Morton
2009-02-02 12:35 ` Rusty Russell
2009-02-03 4:06 ` Andrew Morton
2009-02-04 2:44 ` Rusty Russell
2009-02-04 3:01 ` Andrew Morton
2009-02-04 10:41 ` Rusty Russell
2009-02-04 15:36 ` Andrew Morton
2009-02-04 21:35 ` Ingo Molnar
2009-02-04 21:48 ` Andrew Morton
2009-02-04 21:54 ` Ingo Molnar
2009-02-04 23:45 ` Rusty Russell
2009-02-05 12:19 ` Pavel Machek
2009-02-05 17:44 ` Dmitry Adamushko
2009-02-10 8:54 ` Rusty Russell
2009-02-10 9:35 ` Andrew Morton
2009-02-11 0:32 ` Rusty Russell
2009-01-16 19:11 ` [PATCH 3/3] cpufreq: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write Mike Travis
2009-01-16 23:38 ` [PATCH 0/3] cpu freq: fix problems with work_on_cpu usage in acpi-cpufreq [PULL request] Mike Travis
2009-01-17 22:08 ` Ingo Molnar
2009-01-19 17:11 ` Mike Travis
2009-01-19 17:26 ` Ingo Molnar
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=20090128114440.77abc1b2.akpm@linux-foundation.org \
--to=akpm@linux-foundation.org \
--cc=cpufreq@vger.kernel.org \
--cc=davej@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=rusty@rustcorp.com.au \
--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.