summaryrefslogtreecommitdiff
path: root/arch/um/drivers/virtio_uml.c
AgeCommit message (Collapse)Author
2019-11-25um: virtio_uml: Disallow modular buildJohannes Berg
This driver *can* be a module, but then its parameters (socket path) are untrusted data from inside the VM, and that isn't allowed. Allow the code to only be built-in to avoid that. Fixes: 5d38f324993f ("um: drivers: Add virtio vhost-user driver") Signed-off-by: Johannes Berg <johannes.berg@intel.com> Acked-by: Anton Ivanov <anton.ivanov@cambridgegreys.co.uk> Signed-off-by: Richard Weinberger <richard@nod.at>
2019-11-25um: virtio: Keep reading on -EAGAINJohannes Berg
When we get an interrupt from the socket getting readable, and start reading, there's a possibility for a race. This depends on the implementation of the device, but e.g. with qemu's libvhost-user, we can see: device virtio_uml --------------------------------------- write header get interrupt read header read body -> returns -EAGAIN write body The -EAGAIN return is because the socket is non-blocking, and then this leads us to abandon this message. In fact, we've already read the header, so when the get another signal/interrupt for the body, we again read it as though it's a new message header, and also abandon it for the same reason (wrong size etc.) This essentially breaks things, and if that message was one that required a response, it leads to a deadlock as the device is waiting for the response but we'll never reply. Fix this by spinning on -EAGAIN as well when we read the message body. We need to handle -EAGAIN as "no message" while reading the header, since we share an interrupt. Note that this situation is highly unlikely to occur in normal usage, since there will be very few messages and only in the startup phase. With the inband call feature this does tend to happen (eventually) though. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2019-11-25um: virtio: Remove device on disconnectJohannes Berg
If the connection drops, just remove the device, we don't try to recover from this right now. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2019-09-15um: virtio: Implement VHOST_USER_PROTOCOL_F_REPLY_ACKJohannes Berg
Implement the VHOST_USER_PROTOCOL_F_REPLY_ACK extension for both slave requests (previous patch) where we have to reply and our own requests where it helps understand if the slave failed. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2019-09-15um: virtio: Implement VHOST_USER_PROTOCOL_F_SLAVE_REQJohannes Berg
Implement the communication channel for the device to notify us of some events, and notably implement the handling of the config updates needed for the combination of this feature and VHOST_USER_PROTOCOL_F_CONFIG. Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at>
2019-09-15um: drivers: Add virtio vhost-user driverErel Geron
This module allows virtio devices to be used over a vhost-user socket. Signed-off-by: Erel Geron <erelx.geron@intel.com> Signed-off-by: Johannes Berg <johannes.berg@intel.com> Signed-off-by: Richard Weinberger <richard@nod.at>