All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Andrew Morton <akpm@linux-foundation.org>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Add kerneldoc for flush_scheduled_work()
Date: Wed, 12 Aug 2009 11:41:19 +0200	[thread overview]
Message-ID: <20090812094119.GC14734@elte.hu> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0908111659510.5845-100000@iolanthe.rowland.org>


* Alan Stern <stern@rowland.harvard.edu> wrote:

> This patch (as1279) adds kerneldoc for flush_scheduled_work()
> containing a stern warning that the function should be avoided.
> 
> Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
> 
> ---
> 
> Index: usb-2.6/kernel/workqueue.c
> ===================================================================
> --- usb-2.6.orig/kernel/workqueue.c
> +++ usb-2.6/kernel/workqueue.c
> @@ -739,6 +739,24 @@ int schedule_on_each_cpu(work_func_t fun
>  	return 0;
>  }
>  
> +/**
> + * flush_scheduled_work - ensure that all work scheduled on keventd_wq has run to completion.
> + *
> + * Blocks until all works on the keventd_wq global workqueue have completed.
> + * We sleep until all works present upon entry have been handled, but we
> + * are not livelocked by new incoming ones.
> + *
> + * Use of this function is discouraged, as it is highly prone to deadlock.
> + * It should never be called from within a work routine on the global
> + * queue, and it should never be called while holding a mutex required
> + * by one of the works on the global queue.  But the fact that keventd_wq
> + * _is_ global means that it can contain works requiring practically any
> + * mutex.  Hence this routine shouldn't be called while holding any mutex.
> + *
> + * Consider using cancel_work_sync() or cancel_delayed_work_sync() instead.
> + * They don't do the same thing (they cancel the work instead of waiting
> + * for it to complete), but in most cases they will suffice.
> + */

Looks good - a small nit: please use proper/consistent line length, 
something like:

/**
 * flush_scheduled_work - ensure that all work scheduled on 
 *			  keventd_wq has run to completion
 *
 * Blocks until all works on the keventd_wq global workqueue have 
 * completed.  We sleep until all works present upon entry have been 
 * handled, but we are not livelocked by new incoming ones.
 *
 * Use of this function is discouraged, as it is highly prone to 
 * deadlock.  It should never be called from within a work routine 
 * on the global queue, and it should never be called while holding 
 * a mutex required by one of the works on the global queue.  But 
 * the fact that keventd_wq _is_ global means that it can contain 
 * works requiring practically any mutex.  Hence this routine 
 * shouldn't be called while holding any mutex.
 *
 * Consider using cancel_work_sync() or cancel_delayed_work_sync() 
 * instead.  They don't do the same thing (they cancel the work 
 * instead of waiting for it to complete), but in most cases they 
 * will suffice.
 */

Thanks,

	Ingo

  reply	other threads:[~2009-08-12  9:41 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-11 21:06 [PATCH] Add kerneldoc for flush_scheduled_work() Alan Stern
2009-08-12  9:41 ` Ingo Molnar [this message]
2009-08-12 10:47   ` Peter Zijlstra
2009-08-12 10:51     ` Ingo Molnar
2009-08-12 14:13       ` Alan Stern
2009-08-12 14:17         ` Ingo Molnar
2009-08-12 15:56           ` [PATCH ver 2] " Alan Stern
2009-08-12 16:22         ` [PATCH] " James Bottomley
2009-08-13  7:25           ` Ingo Molnar
2009-08-13  8:47             ` Johannes Weiner
2009-08-13 10:03               ` Ingo Molnar
2009-08-13 14:37             ` James Bottomley
2009-08-12 14:01 ` James Bottomley
2009-08-12 14:54   ` Alan Stern
2009-08-12 15:00     ` James Bottomley
2009-08-12 15:44       ` Alan Stern
2009-08-12 15:58         ` James Bottomley
2009-08-12 16:23           ` Alan Stern
2009-08-12 17:02             ` James Bottomley
2009-08-12 17:25               ` Alan Stern
2009-08-12 17:36                 ` James Bottomley
2009-08-12 18:16                   ` Alan Stern
2009-08-12 18:27                     ` James Bottomley
2009-08-12 18:48                       ` Alan Stern
2009-08-12 20:28                         ` James Bottomley
2009-08-12 20:41                           ` Alan Stern
  -- strict thread matches above, loose matches on Subject: below --
2009-08-12 18:14 Randy Dunlap
2009-08-13 12:06 Randy Dunlap
2009-08-13 14:51 ` Johannes Weiner
2009-08-13 15:04   ` James Bottomley
2009-08-13 16:20     ` Randy Dunlap
2009-08-13 18:08       ` Johannes Weiner
2009-08-14 18:23         ` Randy Dunlap
2009-08-18  9:04           ` Johannes Weiner
2009-08-19 22:23             ` Johannes Weiner
2009-08-19 23:21               ` Randy Dunlap
2009-08-19 23:27                 ` Randy Dunlap
2009-08-24 19:06                 ` Johannes Weiner
2009-08-24 19:27                   ` Randy Dunlap
2009-08-24 20:09                     ` Johannes Weiner
2009-08-24 20:25                       ` Randy Dunlap

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=20090812094119.GC14734@elte.hu \
    --to=mingo@elte.hu \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=stern@rowland.harvard.edu \
    /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.