On Mon, Apr 13, 2026 at 03:22:49PM +0800, Jinhui Guo wrote:
> virtqueue_exec_admin_cmd() holds admin_vq->lock with spin_lock_irqsave(),
> which disables interrupts. Using GFP_KERNEL inside this critical section
> is unsafe because kmalloc() may sleep, leading to potential deadlocks or
> scheduling violations.
>
> Switch to GFP_ATOMIC to ensure the allocation is non-blocking.
>
> Fixes: 4c3b54af907e ("virtio_pci_modern: use completion instead of busy loop
> to wait on admin cmd result")
> Cc: [email protected]
> Signed-off-by: Jinhui Guo <[email protected]>
> ---
> drivers/virtio/virtio_pci_modern.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/virtio/virtio_pci_modern.c
> b/drivers/virtio/virtio_pci_modern.c
> index 6d8ae2a6a8ca..db8e4f88b749 100644
> --- a/drivers/virtio/virtio_pci_modern.c
> +++ b/drivers/virtio/virtio_pci_modern.c
> @@ -101,7 +101,7 @@ static int virtqueue_exec_admin_cmd(struct
> virtio_pci_admin_vq *admin_vq,
> return -EIO;
>
> spin_lock_irqsave(&admin_vq->lock, flags);
> - ret = virtqueue_add_sgs(vq, sgs, out_num, in_num, cmd, GFP_KERNEL);
> + ret = virtqueue_add_sgs(vq, sgs, out_num, in_num, cmd, GFP_ATOMIC);
> if (ret < 0) {
> if (ret == -ENOSPC) {
> spin_unlock_irqrestore(&admin_vq->lock, flags);
GFP_ATOMIC allocations can and will fail. If using them, one must
retry, not just propagate failures.
Or just switch admin_vq->lock to a mutex?
> --
> 2.20.1
