[PATCH v2 2/2] xen/pvcalls: destroy the per-socket workqueue on release

[Yehyeong Lee <yhlee@xxxxxxxxxxxxxxxxxx>]

pvcalls_new_active_socket() gives every active socket its own ordered
workqueue:

        map->ioworker.wq = alloc_ordered_workqueue("pvcalls_io", 0);

and nothing ever destroys it.  pvcalls_back_release_active() flushes
map->ioworker.register_work and frees map, but the workqueue and its
pool_workqueues stay allocated, so a frontend leaks a workqueue per socket
it connects and releases - a loop a guest can run as long as it likes.

Destroy it right after flush_work(): the IRQ is disabled and sk_data_ready
restored by then, so nothing can queue new work, and the rings are still
mapped while it drains - pvcalls_conn_back_read() reads map->ring and
map->data, which xenbus_unmap_ring_vfree() takes away a few lines later.
pvcalls_back_ioworker() does not take fedata->socket_lock, which the
backend_disconnect() caller holds here - only the socket's own
sk_receive_queue lock - so draining it from this point is safe; the
flush_work() just above already has the same requirement.

Fixes: 5db4d286a8ef ("xen/pvcalls: implement connect command")
Cc: stable@xxxxxxxxxxxxxxx
Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>
Signed-off-by: Yehyeong Lee <yhlee@xxxxxxxxxxxxxxxxxx>
---
v2: destroy_workqueue() moved to just after flush_work() (Stefano).  v1: 
https://lore.kernel.org/all/20261109122324.30134-1-yhlee@xxxxxxxxxxxxxxxxxx/

 drivers/xen/pvcalls-back.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/xen/pvcalls-back.c b/drivers/xen/pvcalls-back.c
index dcefa91a40cd05..d97c5eca5f3513 100644
--- a/drivers/xen/pvcalls-back.c
+++ b/drivers/xen/pvcalls-back.c
@@ -452,6 +452,7 @@ static int pvcalls_back_release_active(struct xenbus_device 
*dev,
 
        atomic_set(&map->release, 1);
        flush_work(&map->ioworker.register_work);
+       destroy_workqueue(map->ioworker.wq);
 
        xenbus_unmap_ring_vfree(dev, map->bytes);
        xenbus_unmap_ring_vfree(dev, (void *)map->ring);
-- 
2.43.0