aboutsummaryrefslogtreecommitdiff
path: root/qemu.nsi
diff options
context:
space:
mode:
authorEmilio G. Cota <cota@braap.org>2017-10-19 16:31:54 -0400
committerRichard Henderson <richard.henderson@linaro.org>2017-10-24 13:53:42 -0700
commitcc689485ee3e9dca05765326ee8fd619a6ec48f0 (patch)
tree11cdf0160feabe75a888736d1cbd4d99c7881c6e /qemu.nsi
parent1c2adb958fc07e5b3e81ed21b801c04a15f41f4f (diff)
downloadqemu-cc689485ee3e9dca05765326ee8fd619a6ec48f0.zip
qemu-cc689485ee3e9dca05765326ee8fd619a6ec48f0.tar.gz
qemu-cc689485ee3e9dca05765326ee8fd619a6ec48f0.tar.bz2
translate-all: exit from tb_phys_invalidate if qht_remove fails
Two or more threads might race while invalidating the same TB. We currently do not check for this at all despite taking tb_lock, which means we would wrongly invalidate the same TB more than once. This bug has actually been hit by users: I recently saw a report on IRC, although I have yet to see the corresponding test case. Fix this by using qht_remove as the synchronization point; if it fails, that means the TB has already been invalidated, and therefore there is nothing left to do in tb_phys_invalidate. Note that this solution works now that we still have tb_lock, and will continue working once we remove tb_lock. Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Signed-off-by: Emilio G. Cota <cota@braap.org> Message-Id: <1508445114-4717-1-git-send-email-cota@braap.org> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
Diffstat (limited to 'qemu.nsi')
0 files changed, 0 insertions, 0 deletions