| commit | 600f5ce356b44d8fa5a611ff6b034eb95ecf04e7 | |
| author | Stefan Hajnoczi <stefanha@redhat.com> | |
| Wed, 16 Nov 2016 20:17:32 +0000 (16 20:17 +0000) | ||
| committer | Michael S. Tsirkin <mst@redhat.com> | |
| Fri, 18 Nov 2016 15:14:10 +0000 (18 17:14 +0200) | ||
| tree | 194fa4413e7dded3bc187ff5a9e1ae7e31822182 | treesnapshot (tar.gz zip) |
| parent | 453ac8835b002263a6b7b0843e7c90fa8b19c869 | commitdiff |
virtio-crypto: fix virtio_queue_set_notification() race
We must check for new virtqueue buffers after re-enabling notifications.
This prevents the race condition where the guest added buffers just
after we stopped popping the virtqueue but before we re-enabled
notifications.
I think the virtio-crypto code was based on virtio-net but this crucial
detail was missed. virtio-net does not have the race condition because
it processes the virtqueue one more time after re-enabling
notifications.
Cc: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
We must check for new virtqueue buffers after re-enabling notifications.
This prevents the race condition where the guest added buffers just
after we stopped popping the virtqueue but before we re-enabled
notifications.
I think the virtio-crypto code was based on virtio-net but this crucial
detail was missed. virtio-net does not have the race condition because
it processes the virtqueue one more time after re-enabling
notifications.
Cc: Gonglei <arei.gonglei@huawei.com>
Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
Tested-by: Alexey Kardashevskiy <aik@ozlabs.ru>
Reviewed-by: Michael S. Tsirkin <mst@redhat.com>
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Reviewed-by: Gonglei <arei.gonglei@huawei.com>
| hw/virtio/virtio-crypto.c | diffblobblamehistory |