summaryrefslogtreecommitdiff
path: root/qemu-tech.texi
diff options
context:
space:
mode:
authorEmilio G. Cota <cota@braap.org>2016-10-05 18:34:39 -0400
committerPaolo Bonzini <pbonzini@redhat.com>2016-10-06 18:04:13 +0200
commit76b553b308dc8671eb672b889b38889b1231cf1e (patch)
tree1b3a541546b49a8cb5ad581e3ed36ade1889d97d /qemu-tech.texi
parentf555a9d0b3c785b698f32e6879e97d0a4b387314 (diff)
downloadqemu-76b553b308dc8671eb672b889b38889b1231cf1e.tar.gz
qht: fix unlock-after-free segfault upon resizing
The old map's bucket locks are being unlocked *after* that same old map has been passed to RCU for destruction. This is a bug that can cause a segfault, since there's no guarantee that the deletion will be deferred (e.g. there may be no concurrent readers). The segfault is easily triggered in RHEL6/CentOS6 with qht-test, particularly on a single-core system or by pinning qht-test to a single core. Fix it by unlocking the map's bucket locks right after having published the new map, and (crucially) before marking the map for deletion via call_rcu(). While at it, expand qht_do_resize() to atomically do (1) a reset, (2) a resize, or (3) a reset+resize. This simplifies the calling code, since the new function (qht_do_resize_reset()) acquires and releases the buckets' locks. Note that no qht_do_reset inline is provided, since it would have no users--qht_reset() already performs a reset without taking ht->lock. Reported-by: Peter Maydell <peter.maydell@linaro.org> Reported-by: Daniel P. Berrange <berrange@redhat.com> Signed-off-by: Emilio G. Cota <cota@braap.org> Message-Id: <1475706880-10667-3-git-send-email-cota@braap.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Diffstat (limited to 'qemu-tech.texi')
0 files changed, 0 insertions, 0 deletions