From: Stefano Stabellini <sstabellini@kernel.org>
To: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
Cc: jgross@suse.com, sstabellini@kernel.org,
oleksandr_tyshchenko@epam.com, boris.ostrovsky@oracle.com,
xen-devel@lists.xenproject.org, linux-kernel@vger.kernel.org,
stable@vger.kernel.org
Subject: Re: [PATCH 2/2] xen/pvcalls: destroy the per-socket workqueue on release
Date: Mon, 9 Nov 2026 16:56:33 -0800 (PST) [thread overview]
Message-ID: <604a9832-80ac-107c-b36f-4bb338519cbc@kernel.org> (raw)
In-Reply-To: <20261109122324.30134-3-yhlee@isslab.korea.ac.kr>
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@vger.kernel.org
> Signed-off-by: Yehyeong Lee <yhlee@isslab.korea.ac.kr>
> ---
> 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@kernel.org>
> sock_release(map->sock);
> kfree(map);
> --
> 2.43.0
>
prev parent reply other threads:[~2026-11-10 0:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-09 12:23 [PATCH 0/2] xen/pvcalls: fix the backend error path and a workqueue leak Yehyeong Lee
2026-11-09 12:23 ` [PATCH 1/2] xen/pvcalls: unwind pvcalls_new_active_socket() step by step Yehyeong Lee
2026-11-10 0:55 ` Stefano Stabellini
2026-11-09 12:23 ` [PATCH 2/2] xen/pvcalls: destroy the per-socket workqueue on release Yehyeong Lee
2026-11-10 0:56 ` Stefano Stabellini [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=604a9832-80ac-107c-b36f-4bb338519cbc@kernel.org \
--to=sstabellini@kernel.org \
--cc=boris.ostrovsky@oracle.com \
--cc=jgross@suse.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleksandr_tyshchenko@epam.com \
--cc=stable@vger.kernel.org \
--cc=xen-devel@lists.xenproject.org \
--cc=yhlee@isslab.korea.ac.kr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®