mirror of
https://github.com/torvalds/linux.git
synced 2024-12-29 06:12:08 +00:00
workqueue: warn about flush_scheduled_work()
This patch (as1319) adds kerneldoc and a pointed warning to flush_scheduled_work(). Signed-off-by: Alan Stern <stern@rowland.harvard.edu> Signed-off-by: Tejun Heo <tj@kernel.org>
This commit is contained in:
parent
47dd5be2d6
commit
eef6a7d5c2
@ -845,6 +845,30 @@ int schedule_on_each_cpu(work_func_t func)
|
||||
return 0;
|
||||
}
|
||||
|
||||
/**
|
||||
* flush_scheduled_work - ensure that any scheduled work has run to completion.
|
||||
*
|
||||
* Forces execution of the kernel-global workqueue and blocks until its
|
||||
* completion.
|
||||
*
|
||||
* Think twice before calling this function! It's very easy to get into
|
||||
* trouble if you don't take great care. Either of the following situations
|
||||
* will lead to deadlock:
|
||||
*
|
||||
* One of the work items currently on the workqueue needs to acquire
|
||||
* a lock held by your code or its caller.
|
||||
*
|
||||
* Your code is running in the context of a work routine.
|
||||
*
|
||||
* They will be detected by lockdep when they occur, but the first might not
|
||||
* occur very often. It depends on what work items are on the workqueue and
|
||||
* what locks they need, which you have no control over.
|
||||
*
|
||||
* In most situations flushing the entire workqueue is overkill; you merely
|
||||
* need to know that a particular work item isn't queued and isn't running.
|
||||
* In such cases you should use cancel_delayed_work_sync() or
|
||||
* cancel_work_sync() instead.
|
||||
*/
|
||||
void flush_scheduled_work(void)
|
||||
{
|
||||
flush_workqueue(keventd_wq);
|
||||
|
Loading…
Reference in New Issue
Block a user