summaryrefslogtreecommitdiff
path: root/hw/9pfs
diff options
context:
space:
mode:
authorGreg Kurz <groug@kaod.org>2017-01-13 18:18:20 +0100
committerGreg Kurz <groug@kaod.org>2017-01-25 09:34:35 +0100
commit0d78289c3dca3de8e614a551a3d4a9415168ace0 (patch)
tree9953e626189e053bcbd95ecba74917b91b587a88 /hw/9pfs
parent6e37f458d2381d3572f94fa0ce5487a3e17209fa (diff)
downloadqemu-0d78289c3dca3de8e614a551a3d4a9415168ace0.tar.gz
9pfs: fix off-by-one error in PDU free list
The server can handle MAX_REQ - 1 PDUs at a time and the virtio-9p device has a MAX_REQ sized virtqueue. If the client manages to fill up the virtqueue, pdu_alloc() will fail and the request won't be processed without any notice to the client (it actually causes the linux 9p client to hang). This has been there since the beginning (commit 9f10751365b2 "virtio-9p: Add a virtio 9p device to qemu"), but it needs an agressive workload to run in the guest to show up. We actually allocate MAX_REQ PDUs and I see no reason not to link them all into the free list, so let's fix the init loop. Reported-by: Tuomas Tynkkynen <tuomas@tuxera.com> Suggested-by: Al Viro <viro@ZenIV.linux.org.uk> Signed-off-by: Greg Kurz <groug@kaod.org>
Diffstat (limited to 'hw/9pfs')
-rw-r--r--hw/9pfs/9p.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/hw/9pfs/9p.c b/hw/9pfs/9p.c
index 58310ca8d5..d2d0288282 100644
--- a/hw/9pfs/9p.c
+++ b/hw/9pfs/9p.c
@@ -3454,7 +3454,7 @@ int v9fs_device_realize_common(V9fsState *s, Error **errp)
/* initialize pdu allocator */
QLIST_INIT(&s->free_list);
QLIST_INIT(&s->active_list);
- for (i = 0; i < (MAX_REQ - 1); i++) {
+ for (i = 0; i < MAX_REQ; i++) {
QLIST_INSERT_HEAD(&s->free_list, &s->pdus[i], next);
s->pdus[i].s = s;
s->pdus[i].idx = i;