aboutsummaryrefslogtreecommitdiffstats
path: root/kernel
diff options
context:
space:
mode:
Diffstat (limited to 'kernel')
-rw-r--r--kernel/workqueue.c24
1 files changed, 24 insertions, 0 deletions
diff --git a/kernel/workqueue.c b/kernel/workqueue.c
index 5bfb213984b2..0225fea89340 100644
--- a/kernel/workqueue.c
+++ b/kernel/workqueue.c
@@ -845,6 +845,30 @@ int schedule_on_each_cpu(work_func_t func)
845 return 0; 845 return 0;
846} 846}
847 847
848/**
849 * flush_scheduled_work - ensure that any scheduled work has run to completion.
850 *
851 * Forces execution of the kernel-global workqueue and blocks until its
852 * completion.
853 *
854 * Think twice before calling this function! It's very easy to get into
855 * trouble if you don't take great care. Either of the following situations
856 * will lead to deadlock:
857 *
858 * One of the work items currently on the workqueue needs to acquire
859 * a lock held by your code or its caller.
860 *
861 * Your code is running in the context of a work routine.
862 *
863 * They will be detected by lockdep when they occur, but the first might not
864 * occur very often. It depends on what work items are on the workqueue and
865 * what locks they need, which you have no control over.
866 *
867 * In most situations flushing the entire workqueue is overkill; you merely
868 * need to know that a particular work item isn't queued and isn't running.
869 * In such cases you should use cancel_delayed_work_sync() or
870 * cancel_work_sync() instead.
871 */
848void flush_scheduled_work(void) 872void flush_scheduled_work(void)
849{ 873{
850 flush_workqueue(keventd_wq); 874 flush_workqueue(keventd_wq);