From: Andrew Morton <akpm@osdl.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: David Howells <dhowells@redhat.com>,
"Maciej W. Rozycki" <macro@linux-mips.org>,
Roland Dreier <rdreier@cisco.com>,
Andy Fleming <afleming@freescale.com>,
Ben Collins <ben.collins@ubuntu.com>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Jeff Garzik <jeff@garzik.org>
Subject: Re: [PATCH] Export current_is_keventd() for libphy
Date: Wed, 6 Dec 2006 22:42:07 -0800 [thread overview]
Message-ID: <20061206224207.8a8335ee.akpm@osdl.org> (raw)
In-Reply-To: <Pine.LNX.4.64.0612061719420.3542@woody.osdl.org>
On Wed, 6 Dec 2006 17:21:50 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Wed, 6 Dec 2006, Linus Torvalds wrote:
> >
> > How about something like this?
>
> I didn't get any answers on this. I'd like to get this issue resolved, but
> since I don't even use libphy on my main machine, I need somebody else to
> test it for me.
>
> Just to remind you all, here's the patch again. This is identical to the
> previous version except for the trivial cleanup to use "work_pending()"
> instead of open-coding it in two places.
>
> Linus
>
> ...
>
> +static int __run_work(struct cpu_workqueue_struct *cwq, struct work_struct *work)
> +{
> + int ret = 0;
> + unsigned long flags;
> +
> + spin_lock_irqsave(&cwq->lock, flags);
> + /*
> + * We need to re-validate the work info after we've gotten
> + * the cpu_workqueue lock. We can run the work now iff:
> + *
> + * - the wq_data still matches the cpu_workqueue_struct
> + * - AND the work is still marked pending
> + * - AND the work is still on a list (which will be this
> + * workqueue_struct list)
> + *
> + * All these conditions are important, because we
> + * need to protect against the work being run right
> + * now on another CPU (all but the last one might be
> + * true if it's currently running and has not been
> + * released yet, for example).
> + */
> + if (get_wq_data(work) == cwq
> + && work_pending(work)
> + && !list_empty(&work->entry)) {
> + work_func_t f = work->func;
> + list_del_init(&work->entry);
> + spin_unlock_irqrestore(&cwq->lock, flags);
> +
> + if (!test_bit(WORK_STRUCT_NOAUTOREL, &work->management))
> + work_release(work);
> + f(work);
> +
> + spin_lock_irqsave(&cwq->lock, flags);
> + cwq->remove_sequence++;
> + wake_up(&cwq->work_done);
> + ret = 1;
> + }
> + spin_unlock_irqrestore(&cwq->lock, flags);
> + return ret;
> +}
> +
> +/**
> + * run_scheduled_work - run scheduled work synchronously
> + * @work: work to run
> + *
> + * This checks if the work was pending, and runs it
> + * synchronously if so. It returns a boolean to indicate
> + * whether it had any scheduled work to run or not.
> + *
> + * NOTE! This _only_ works for normal work_structs. You
> + * CANNOT use this for delayed work, because the wq data
> + * for delayed work will not point properly to the per-
> + * CPU workqueue struct, but will change!
> + */
> +int fastcall run_scheduled_work(struct work_struct *work)
> +{
> + for (;;) {
> + struct cpu_workqueue_struct *cwq;
> +
> + if (!work_pending(work))
> + return 0;
But this will return to the caller if the callback is presently running on
a different CPU. The whole point here is to be able to reliably kill off
the pending work so that the caller can free resources.
> + if (list_empty(&work->entry))
> + return 0;
> + /* NOTE! This depends intimately on __queue_work! */
> + cwq = get_wq_data(work);
> + if (!cwq)
> + return 0;
> + if (__run_work(cwq, work))
> + return 1;
> + }
> +}
> +EXPORT_SYMBOL(run_scheduled_work);
Also, I worry that this code can run the callback on the caller's CPU.
Users of per-cpu workqueues can legitimately assume that each callback runs
on the right CPU. I doubt if many callers _do_ do that - there's
schedule_delayed_work_on(), but that's a bit different.
A solution to both problems is of course to block the caller if the
callback is running. We can perhaps borrow cwq->work_done for that.
But I wouldn't want to think about an implementation as long as we have
that WORK_STRUCT_NOAUTOREL horror in there. Can we just nuke that? Only
three drivers need it and I bet they can be modified to use the usual
mechanisms.
next prev parent reply other threads:[~2006-12-07 6:42 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-03 5:50 [PATCH] Export current_is_keventd() for libphy Ben Collins
2006-12-03 9:16 ` Andrew Morton
2006-12-04 19:17 ` Steve Fox
2006-12-05 18:05 ` Maciej W. Rozycki
2006-12-05 17:48 ` Maciej W. Rozycki
2006-12-05 18:07 ` Linus Torvalds
2006-12-05 19:31 ` Andrew Morton
2006-12-05 18:57 ` Andy Fleming
2006-12-06 12:31 ` Maciej W. Rozycki
2006-12-05 20:39 ` Andrew Morton
2006-12-05 20:59 ` Andy Fleming
2006-12-05 21:26 ` Andrew Morton
2006-12-05 21:37 ` Roland Dreier
2006-12-05 21:57 ` Andrew Morton
2006-12-05 23:49 ` Roland Dreier
2006-12-05 23:52 ` Roland Dreier
2006-12-06 15:25 ` Maciej W. Rozycki
2006-12-06 15:57 ` Andrew Morton
2006-12-06 17:17 ` Linus Torvalds
2006-12-06 17:43 ` David Howells
2006-12-06 17:50 ` Jeff Garzik
2006-12-06 18:07 ` Linus Torvalds
2006-12-06 17:53 ` Linus Torvalds
2006-12-06 17:58 ` Linus Torvalds
2006-12-06 18:33 ` Linus Torvalds
2006-12-06 18:37 ` Linus Torvalds
2006-12-06 18:43 ` David Howells
2006-12-06 19:02 ` Linus Torvalds
2006-12-06 18:02 ` David Howells
2006-12-07 1:21 ` Linus Torvalds
2006-12-07 6:42 ` Andrew Morton [this message]
2006-12-07 7:49 ` Andrew Morton
2006-12-07 10:29 ` David Howells
2006-12-07 10:42 ` Andrew Morton
2006-12-07 17:05 ` Jeff Garzik
2006-12-07 17:57 ` Andrew Morton
2006-12-07 18:17 ` Andrew Morton
2006-12-08 16:52 ` [PATCH] group xtime, xtime_lock, wall_to_monotonic, avenrun, calc_load_count fields together in ktimed Eric Dumazet
2006-12-09 5:46 ` Andrew Morton
2006-12-09 6:07 ` Randy Dunlap
2006-12-11 20:44 ` Eric Dumazet
2006-12-11 22:00 ` Andrew Morton
2006-12-13 21:26 ` [PATCH] Introduce time_data, a new structure to hold jiffies, xtime, xtime_lock, wall_to_monotonic, calc_load_count and avenrun Eric Dumazet
2006-12-15 5:24 ` Andrew Morton
2006-12-15 11:21 ` Eric Dumazet
2006-12-15 16:21 ` Eric Dumazet
2006-12-07 18:08 ` [PATCH] Export current_is_keventd() for libphy Maciej W. Rozycki
2006-12-07 18:59 ` Andy Fleming
2006-12-07 16:49 ` Linus Torvalds
2006-12-07 17:52 ` Andrew Morton
2006-12-07 18:01 ` Linus Torvalds
2006-12-07 18:16 ` Andrew Morton
2006-12-07 18:27 ` Linus Torvalds
2006-12-07 15:28 ` Maciej W. Rozycki
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=20061206224207.8a8335ee.akpm@osdl.org \
--to=akpm@osdl.org \
--cc=afleming@freescale.com \
--cc=ben.collins@ubuntu.com \
--cc=dhowells@redhat.com \
--cc=jeff@garzik.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@linux-mips.org \
--cc=rdreier@cisco.com \
--cc=torvalds@osdl.org \
/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.