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

[Stefano Stabellini]

On Mon, 9 Nov 2026, Yehyeong Lee wrote:
> 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 after the IRQ is unbound, so no new work can be queued, and
> before map is freed.  pvcalls_back_ioworker() takes no locks, in
> particular not fedata->socket_lock, which the backend_disconnect() caller
> holds here, 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
> Signed-off-by: Yehyeong Lee <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..27aa06289a7b92 100644
> --- a/drivers/xen/pvcalls-back.c
> +++ b/drivers/xen/pvcalls-back.c
> @@ -456,6 +456,7 @@ static int pvcalls_back_release_active(struct xenbus_device *dev,
>  	xenbus_unmap_ring_vfree(dev, map->bytes);
>  	xenbus_unmap_ring_vfree(dev, (void *)map->ring);
>  	unbind_from_irqhandler(map->irq, map);
> +	destroy_workqueue(map->ioworker.wq);

Please move the call to destroy_workqueue() just after flush_work().
With that:

Reviewed-by: Stefano Stabellini <sstabellini@xxxxxxxxxx>


>  	sock_release(map->sock);
>  	kfree(map);
> -- 
> 2.43.0
>