public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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.


  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox