summaryrefslogtreecommitdiffstats
path: root/contrib/llvm/lib/Analysis/LoopInfo.cpp
diff options
context:
space:
mode:
authordelphij <delphij@FreeBSD.org>2015-05-26 01:40:33 +0000
committerdelphij <delphij@FreeBSD.org>2015-05-26 01:40:33 +0000
commit3c3588ac3e1c879cd36168eb5d42e8a0d52c4a70 (patch)
tree18254e1f5e0ac91b9b719b3e738b5c867c0c82a7 /contrib/llvm/lib/Analysis/LoopInfo.cpp
parente680cfdaff00ea510fd20d4a429218ba527d813e (diff)
downloadFreeBSD-src-3c3588ac3e1c879cd36168eb5d42e8a0d52c4a70.zip
FreeBSD-src-3c3588ac3e1c879cd36168eb5d42e8a0d52c4a70.tar.gz
MFuser/delphij/zfs-arc-rebase@r281754:
In r256613, taskqueue_enqueue_locked() have been modified to release the task queue lock before returning. In r276665, taskqueue_drain_all() will call taskqueue_enqueue_locked() to insert the barrier task into the queue, but did not reacquire the lock after it but later code expects the lock still being held (e.g. TQ_SLEEP()). The barrier task is special and if we release then reacquire the lock, there would be a small race window where a high priority task could sneak into the queue. Looking more closely, the race seems to be tolerable but is undesirable from semantics standpoint. To solve this, in taskqueue_drain_tq_queue(), instead of directly calling taskqueue_enqueue_locked(), insert the barrier task directly without releasing the lock.
Diffstat (limited to 'contrib/llvm/lib/Analysis/LoopInfo.cpp')
0 files changed, 0 insertions, 0 deletions
OpenPOWER on IntegriCloud