diff options
author | delphij <delphij@FreeBSD.org> | 2015-05-26 01:40:33 +0000 |
---|---|---|
committer | delphij <delphij@FreeBSD.org> | 2015-05-26 01:40:33 +0000 |
commit | 3c3588ac3e1c879cd36168eb5d42e8a0d52c4a70 (patch) | |
tree | 18254e1f5e0ac91b9b719b3e738b5c867c0c82a7 /contrib/llvm/lib/Analysis/LoopInfo.cpp | |
parent | e680cfdaff00ea510fd20d4a429218ba527d813e (diff) | |
download | FreeBSD-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