| Message ID | 2cc8d6c4ae9fa8210c48c349b207dfb68cb15290.1589481482.git.qemu_oss@crudebyte.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | virtio-9pfs: don't truncate response | expand |
On Thu, 14 May 2020, Christian Schoenebeck wrote: > Commit SHA-1 16724a173049ac29c7b5ade741da93a0f46edff7 introduced > truncating the response to the currently available transport buffer size, > which was supposed to fix an 9pfs error on Xen boot where transport buffer > might still be smaller than required for response. > > Unfortunately this change broke small reads (with less than 12 bytes). > > To fix this introduced bug for virtio at least, let's revert this change > for the virtio transport. Unlike with Xen, we should never come into > this situation with virtio that the available transport buffer would be > too small for delivering any response to client. So truncating the buffer > is not necessary with virtio in the first place. > > This bug still needs to be addressed for Xen appropriately though. > > Fixes: 16724a173049ac29c7b5ade741da93a0f46edff7 (for virtio only) > Fixes: https://bugs.launchpad.net/bugs/1877688 (for virtio only) > Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org> > --- > hw/9pfs/virtio-9p-device.c | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c > index 536447a355..bb6154945a 100644 > --- a/hw/9pfs/virtio-9p-device.c > +++ b/hw/9pfs/virtio-9p-device.c > @@ -154,16 +154,13 @@ static void virtio_init_in_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, > VirtQueueElement *elem = v->elems[pdu->idx]; > size_t buf_size = iov_size(elem->in_sg, elem->in_num); > > - if (buf_size < P9_IOHDRSZ) { > + if (buf_size < *size) { > VirtIODevice *vdev = VIRTIO_DEVICE(v); > > virtio_error(vdev, > - "VirtFS reply type %d needs %zu bytes, buffer has %zu, less than minimum", > + "VirtFS reply type %d needs %zu bytes, buffer has %zu", > pdu->id + 1, *size, buf_size); > } > - if (buf_size < *size) { > - *size = buf_size; > - } > > *piov = elem->in_sg; > *pniov = elem->in_num; > -- > 2.20.1 >
diff --git a/hw/9pfs/virtio-9p-device.c b/hw/9pfs/virtio-9p-device.c index 536447a355..bb6154945a 100644 --- a/hw/9pfs/virtio-9p-device.c +++ b/hw/9pfs/virtio-9p-device.c @@ -154,16 +154,13 @@ static void virtio_init_in_iov_from_pdu(V9fsPDU *pdu, struct iovec **piov, VirtQueueElement *elem = v->elems[pdu->idx]; size_t buf_size = iov_size(elem->in_sg, elem->in_num); - if (buf_size < P9_IOHDRSZ) { + if (buf_size < *size) { VirtIODevice *vdev = VIRTIO_DEVICE(v); virtio_error(vdev, - "VirtFS reply type %d needs %zu bytes, buffer has %zu, less than minimum", + "VirtFS reply type %d needs %zu bytes, buffer has %zu", pdu->id + 1, *size, buf_size); } - if (buf_size < *size) { - *size = buf_size; - } *piov = elem->in_sg; *pniov = elem->in_num;
Commit SHA-1 16724a173049ac29c7b5ade741da93a0f46edff7 introduced truncating the response to the currently available transport buffer size, which was supposed to fix an 9pfs error on Xen boot where transport buffer might still be smaller than required for response. Unfortunately this change broke small reads (with less than 12 bytes). To fix this introduced bug for virtio at least, let's revert this change for the virtio transport. Unlike with Xen, we should never come into this situation with virtio that the available transport buffer would be too small for delivering any response to client. So truncating the buffer is not necessary with virtio in the first place. This bug still needs to be addressed for Xen appropriately though. Fixes: 16724a173049ac29c7b5ade741da93a0f46edff7 (for virtio only) Fixes: https://bugs.launchpad.net/bugs/1877688 (for virtio only) Signed-off-by: Christian Schoenebeck <qemu_oss@crudebyte.com> --- hw/9pfs/virtio-9p-device.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)