diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2015-03-09 17:00:54 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2015-03-09 17:00:54 -0700 |
commit | b695f31f4efd91c7cab97324ccbcb33201ebaaa2 (patch) | |
tree | 0cb3111136ba025dfa08a5908cbd241bbc37d011 /Documentation/leds | |
parent | 9eccca0843205f87c00404b663188b88eb248051 (diff) | |
parent | 8603e1b30027f943cc9c1eef2b291d42c3347af1 (diff) | |
download | linux-b695f31f4efd91c7cab97324ccbcb33201ebaaa2.tar.bz2 |
Merge branch 'for-4.0-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq
Pull workqueue fix from Tejun Heo:
"One fix patch for a subtle livelock condition which can happen on
PREEMPT_NONE kernels involving two racing cancel_work calls. Whoever
comes in the second has to wait for the previous one to finish. This
was implemented by making the later one block for the same condition
that the former would be (work item completion) and then loop and
retest; unfortunately, depending on the wake up order, the later one
could lock out the former one to finish by busy looping on the cpu.
This is fixed by implementing explicit wait mechanism. Work item
might not belong anywhere at this point and there's remote possibility
of thundering herd problem. I originally tried to use bit_waitqueue
but it didn't work for static work items on modules. It's currently
using single wait queue with filtering wake up function and exclusive
wakeup. If this ever becomes a problem, which is not very likely, we
can try to figure out a way to piggy back on bit_waitqueue"
* 'for-4.0-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
workqueue: fix hang involving racing cancel[_delayed]_work_sync()'s for PREEMPT_NONE
Diffstat (limited to 'Documentation/leds')
0 files changed, 0 insertions, 0 deletions