task_work_run: don't take ->pi_lock unconditionally
As Peter pointed out, task_work() can avoid ->pi_lock and cmpxchg() if task->task_works == NULL && !PF_EXITING. And in fact the only reason why task_work_run() needs ->pi_lock is the possible race with task_work_cancel(), we can optimize this code and make the locking more clear. Signed-off-by: Oleg Nesterov <oleg@redhat.com> Signed-off-by: Jens Axboe <axboe@kernel.dk>
This commit is contained in:
parent
3684f24653
commit
6fb614920b
|
@ -97,16 +97,26 @@ void task_work_run(void)
|
||||||
* work->func() can do task_work_add(), do not set
|
* work->func() can do task_work_add(), do not set
|
||||||
* work_exited unless the list is empty.
|
* work_exited unless the list is empty.
|
||||||
*/
|
*/
|
||||||
raw_spin_lock_irq(&task->pi_lock);
|
|
||||||
do {
|
do {
|
||||||
|
head = NULL;
|
||||||
work = READ_ONCE(task->task_works);
|
work = READ_ONCE(task->task_works);
|
||||||
head = !work && (task->flags & PF_EXITING) ?
|
if (!work) {
|
||||||
&work_exited : NULL;
|
if (task->flags & PF_EXITING)
|
||||||
|
head = &work_exited;
|
||||||
|
else
|
||||||
|
break;
|
||||||
|
}
|
||||||
} while (cmpxchg(&task->task_works, work, head) != work);
|
} while (cmpxchg(&task->task_works, work, head) != work);
|
||||||
raw_spin_unlock_irq(&task->pi_lock);
|
|
||||||
|
|
||||||
if (!work)
|
if (!work)
|
||||||
break;
|
break;
|
||||||
|
/*
|
||||||
|
* Synchronize with task_work_cancel(). It can not remove
|
||||||
|
* the first entry == work, cmpxchg(task_works) must fail.
|
||||||
|
* But it can remove another entry from the ->next list.
|
||||||
|
*/
|
||||||
|
raw_spin_lock_irq(&task->pi_lock);
|
||||||
|
raw_spin_unlock_irq(&task->pi_lock);
|
||||||
|
|
||||||
do {
|
do {
|
||||||
next = work->next;
|
next = work->next;
|
||||||
|
|
Loading…
Reference in New Issue