I can apply it with these fixes on my side: - the first sentence says the hang needs vhost_task workers - the work item is needed because releasing a request takes vq->mutex and flush_lock, not because of kvfree() - dropped the sentence about VHOST_RESET_OWNER
On Fri, 13 Nov 2026 09:27:43 +0100, Alexander Ivanov wrote: > When the owner is killed, vhost_worker_killed() detaches the worker > from the virtqueues and runs only the work already queued. Changed to "With vhost_task workers (not the default kthread ones), killing the owner makes vhost_worker_killed() detach the worker ...". Why: vhost_worker_killed() exists only for vhost_task workers. Our kernel defaults to kthread workers (fork_from_owner_default), and our QEMU does not ask for a vhost_task. A kthread worker is not killed with QEMU and completes the requests, so the default setup does not hang. > completion may run in interrupt context, where forget_request() and > the kvfree() of the request buffers are not allowed. Changed to "where a request cannot be released: that takes vq->mutex, and flush_lock with plain spin_lock()". Why: kvfree() is allowed there, vfree() defers itself when in_interrupt(). > requests. Flushing there rather than in release also keeps a stale > drop work from releasing requests of the next owner after > VHOST_RESET_OWNER. Dropped. Why: the drop work is queued only after the owner was killed, and then nobody passes vhost_dev_check_owner(), so no VHOST_RESET_OWNER can follow. The flush is in vhost_blk_drop_backend() because the requests are freed right after it, which the sentence before already says. -- Konstantin Khorenko, Virtuozzo Linux Kernel Team _______________________________________________ Devel mailing list [email protected] https://lists.openvz.org/mailman/listinfo/devel
