mirror of
https://github.com/Fishwaldo/Star64_linux.git
synced 2025-06-19 13:11:14 +00:00
workqueue: move flush_scheduled_work() to workqueue.h
flush_scheduled_work() is just a simple call to flush_work(). Signed-off-by: Lai Jiangshan <laijs@cn.fujitsu.com> Signed-off-by: Tejun Heo <tj@kernel.org>
This commit is contained in:
parent
899a94fe15
commit
37b1ef31a5
2 changed files with 29 additions and 31 deletions
|
@ -2958,36 +2958,6 @@ 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(system_wq);
|
||||
}
|
||||
EXPORT_SYMBOL(flush_scheduled_work);
|
||||
|
||||
/**
|
||||
* execute_in_process_context - reliably execute the routine with user context
|
||||
* @fn: the function to execute
|
||||
|
|
Loading…
Add table
Add a link
Reference in a new issue