This fixes an issue found by stress-testing device removal
of virtio console, as well as a similar issue found by
code review in virtio mem.
Changes from v1:
- added documentation
- added virtio mem changes
- missing new line in virtio console change
v1 Link: https://lore.kernel.org/r/[email protected]
Michael S. Tsirkin (3):
virtio: document virtio_reset_device
virtio_console: break out of buf poll on remove
virtio_mem: break device on remove
drivers/char/virtio_console.c | 7 +++++++
drivers/virtio/virtio.c | 16 ++++++++++++++++
drivers/virtio/virtio_mem.c | 2 ++
3 files changed, 25 insertions(+)
--
MST
Looks like most callers get driver/device removal wrong.
Document what's expected of callers.
Signed-off-by: Michael S. Tsirkin <[email protected]>
---
drivers/virtio/virtio.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
index 2ed6e2451fd8..631a346a3aa6 100644
--- a/drivers/virtio/virtio.c
+++ b/drivers/virtio/virtio.c
@@ -201,6 +201,22 @@ static int virtio_finalize_features(struct virtio_device *dev)
return 0;
}
+/**
+ * virtio_reset_device - quiesce device for removal
+ * @dev: the device to reset
+ *
+ * Prevents device from sending interrupts and accessing memory.
+ *
+ * Generally used for cleanup during driver / device removal.
+ *
+ * Once this has been invoked, caller must ensure that
+ * virtqueue_notify / virtqueue_kick are not in progress.
+ *
+ * Note: this guarantees that vq callbacks are not in progress, however caller
+ * is responsible for preventing access from other contexts, such as a system
+ * call/workqueue/bh. Invoking virtio_break_device then flushing any such
+ * contexts is one way to handle that.
+ * */
void virtio_reset_device(struct virtio_device *dev)
{
dev->config->reset(dev);
--
MST