diff options
author | Linus Torvalds <torvalds@linux-foundation.org> | 2016-04-27 12:03:59 -0700 |
---|---|---|
committer | Linus Torvalds <torvalds@linux-foundation.org> | 2016-04-27 12:03:59 -0700 |
commit | b75a2bf899b668b1d52de8846aafdbcf81349c73 (patch) | |
tree | 6696988bd5a31543833d4b275605d766e0a20840 /kernel/kexec_core.c | |
parent | 763cfc86ee8fd728a7cf2334b8d3a897af7a7ade (diff) | |
parent | 346c09f80459a3ad97df1816d6d606169a51001a (diff) | |
download | op-kernel-dev-b75a2bf899b668b1d52de8846aafdbcf81349c73.zip op-kernel-dev-b75a2bf899b668b1d52de8846aafdbcf81349c73.tar.gz |
Merge branch 'for-4.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq
Pull workqueue fix from Tejun Heo:
"So, it turns out we had a silly bug in the most fundamental part of
workqueue for a very long time. AFAICS, this dates back to pre-git
era and has quite likely been there from the time workqueue was first
introduced.
A work item uses its PENDING bit to synchronize multiple queuers.
Anyone who wins the PENDING bit owns the pending state of the work
item. Whether a queuer wins or loses the race, one thing should be
guaranteed - there will soon be at least one execution of the work
item - where "after" means that the execution instance would be able
to see all the changes that the queuer has made prior to the queueing
attempt.
Unfortunately, we were missing a smp_mb() after clearing PENDING for
execution, so nothing guaranteed visibility of the changes that a
queueing loser has made, which manifested as a reproducible blk-mq
stall.
Lots of kudos to Roman for debugging the problem. The patch for
-stable is the minimal one. For v3.7, Peter is working on a patch to
make the code path slightly more efficient and less fragile"
* 'for-4.6-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/wq:
workqueue: fix ghost PENDING flag while doing MQ IO
Diffstat (limited to 'kernel/kexec_core.c')
0 files changed, 0 insertions, 0 deletions