Michael S. Tsirkin
2014-Nov-25 16:42 UTC
[PATCH v4 19/42] virtio_blk: fix race at module removal
If a device appears while module is being removed,
driver will get a callback after we've given up
on the major number.
In theory this means this major number can get reused
by something else, resulting in a conflict.
Signed-off-by: Michael S. Tsirkin <mst at redhat.com>
---
drivers/block/virtio_blk.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/block/virtio_blk.c b/drivers/block/virtio_blk.c
index 055f3df..1f8b111 100644
--- a/drivers/block/virtio_blk.c
+++ b/drivers/block/virtio_blk.c
@@ -884,8 +884,8 @@ out_destroy_workqueue:
static void __exit fini(void)
{
- unregister_blkdev(major, "virtblk");
unregister_virtio_driver(&virtio_blk);
+ unregister_blkdev(major, "virtblk");
destroy_workqueue(virtblk_wq);
}
module_init(init);
--
MST
Cornelia Huck
2014-Nov-26 09:53 UTC
[PATCH v4 19/42] virtio_blk: fix race at module removal
On Tue, 25 Nov 2014 18:42:46 +0200 "Michael S. Tsirkin" <mst at redhat.com> wrote:> If a device appears while module is being removed, > driver will get a callback after we've given up > on the major number. > > In theory this means this major number can get reused > by something else, resulting in a conflict. > > Signed-off-by: Michael S. Tsirkin <mst at redhat.com> > --- > drivers/block/virtio_blk.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) >Acked-by: Cornelia Huck <cornelia.huck at de.ibm.com> This and the previous patch are independent of virtio 1.0, aren't they? Maybe you should put them at the top of your queue :)
Seemingly Similar Threads
- [PATCH v4 19/42] virtio_blk: fix race at module removal
- [PATCH v7 22/46] virtio_blk: fix race at module removal
- [PATCH v7 22/46] virtio_blk: fix race at module removal
- [PATCH v3 18/41] virtio_blk: fix race at module removal
- [PATCH v5 21/45] virtio_blk: fix race at module removal