On Tue, Sep 15, 2026 at 04:38:38PM -0500, Mike Christie wrote:
> On 9/8/26 9:30 AM, Linfeng Sun wrote:
> > vhost_scsi_set_endpoint() allocates command pools only for I/O virtqueues
> > that
> > are already set up, but publishes the backend for every virtqueue. If
> > userspace
> > finishes configuring a skipped queue later, a kick reaches
> > vhost_scsi_get_cmd() with
> >
> >
> > vhost_scsi_set_endpoint() allocates command pools only for I/O virtqueues
> > that are already set up, but publishes the backend for every virtqueue. If
> > userspace finishes configuring a skipped queue later, a kick reaches
> > vhost_scsi_get_cmd() with scsi_tags uninitialized and triggers the
> > !sb->alloc_hint warning in sbitmap_get().
> >
> > Leave skipped I/O virtqueues inactive at SET_ENDPOINT. When SET_VRING_ADDR
> > later completes their setup, allocate the command pools and activate the
> > queues. Roll back both if access initialization fails.
> >
> > Fixes: 25b98b64e284 ("vhost scsi: alloc cmds per vq instead of session")
> > Signed-off-by: Linfeng Sun <[email protected]>
> > ---
> > I checked QEMU and found no evidence it's affected. I haven't checked
> > VirtualBox because I am not familiar with it. However, the virtio spec
> > doesn't require a specific operation order, so a new VMM could still
> > trigger this issue.
> >
> > Crash log:
> > [ 34.698961] ------------[ cut here ]------------
> > [ 34.699385] WARNING: lib/sbitmap.c:286 at sbitmap_get+0x227/0x270,
> > CPU#0: vhost-82/88
> > [ 34.700542] Modules linked in:
> > [ 34.701309] CPU: 0 UID: 0 PID: 88 Comm: vhost-82 Not tainted 7.3.0-rc2+
> > #14 PREEMPT(full)
> > [ 34.701958] Hardware name: QEMU Ubuntu 24.04 PC v2 (i440FX + PIIX,
> > arch_caps fix, 1996), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
> > [ 34.702717] RIP: 0010:sbitmap_get+0x227/0x270
> > [ 34.703247] Code: 41 8d 5d 01 89 df 44 89 fe e8 f5 3a 46 ff 31 c0 44 39
> > fb 0f 43 d8 e8 38 46 46 ff 65 41 89 1c 24 e9 25 ff ff ff e8 29 46 46 ff
> > <0f> 0b eb ba e8 20 46 46 ff 44 89 fe 31 ff 45 31 e4 e8 c3 3b 46 ff
> > [ 34.704234] RSP: 0018:ffffc90000ec3bb0 EFLAGS: 00000246
> > [ 34.704677] RAX: 0000000000000000 RBX: ffff88800500dee8 RCX:
> > 0000000000000000
> > [ 34.705166] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> > ffff88800500dee8
> > [ 34.705584] RBP: ffffc90000ec3be0 R08: 0000000000000000 R09:
> > 0000000000000000
> > [ 34.705988] R10: 0000000000000000 R11: 0000000000000000 R12:
> > 0000000000000006
> > [ 34.706477] R13: 0000000000000000 R14: 0000000000000000 R15:
> > ffff8880050094d0
> > [ 34.706955] FS: 0000000014d05380(0000) GS:ffff888099c36000(0000)
> > knlGS:0000000000000000
> > [ 34.707463] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > [ 34.707854] CR2: 00007c0c3c20e000 CR3: 0000000008e47000 CR4:
> > 00000000000006f0
> > [ 34.708592] Call Trace:
> > [ 34.709259] <TASK>
> > [ 34.709822] vhost_scsi_handle_vq+0x4a9/0x1b20
> > [ 34.710437] ? update_cfs_rq_load_avg+0x2e/0x230
> > [ 34.710874] vhost_scsi_handle_kick+0x2c/0x40
> > [ 34.711292] vhost_run_work_list+0xa6/0xf0
> > [ 34.711673] vhost_task_fn+0x76/0x1b0
> > [ 34.712003] ? __sanitizer_cov_trace_const_cmp1+0x1a/0x30
> > [ 34.712506] ? recalc_sigpending+0xe1/0x130
> > [ 34.712890] ? __pfx_vhost_task_fn+0x10/0x10
> > [ 34.713325] ret_from_fork+0x37a/0x630
> > [ 34.713673] ? __pfx_vhost_task_fn+0x10/0x10
> > [ 34.714031] ret_from_fork_asm+0x1a/0x30
> > [ 34.714535] RIP: 0033:0x0
> > [ 34.715201] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
> > [ 34.715587] RSP: 002b:0000000000000000 EFLAGS: 00000246 ORIG_RAX:
> > 0000000000000010
> > [ 34.716158] RAX: 0000000000000000 RBX: 000000000048bb20 RCX:
> > 000000000041ca3d
> > [ 34.716571] RDX: 0000000000000000 RSI: 0000000000000000 RDI:
> > 0000000000000003
> > [ 34.716957] RBP: 00007ffcac47c4e0 R08: 00000000ffffffff R09:
> > 0000000000000000
> > [ 34.717418] R10: 0000000000000000 R11: 0000000000000246 R12:
> > 0000000000000004
> > [ 34.717826] R13: 00007ffcac47c778 R14: 00000000004af868 R15:
> > 0000000000000001
> > [ 34.718363] </TASK>
> > ---
> > drivers/vhost/scsi.c | 44 ++++++++++++++++++++++++++++++++++++++++++--
> > 1 file changed, 42 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vhost/scsi.c b/drivers/vhost/scsi.c
> > index 4f8c0260bc9e..069a6ff4dd40 100644
> > --- a/drivers/vhost/scsi.c
> > +++ b/drivers/vhost/scsi.c
> > @@ -2008,6 +2008,40 @@ static int vhost_scsi_setup_vq_cmds(struct
> > vhost_virtqueue *vq, int max_cmds)
> > return -ENOMEM;
> > }
> >
> > +/* Callers must hold dev mutex. */
> > +static int vhost_scsi_activate_vqs(struct vhost_scsi *vs)
> > +{
> > + struct vhost_virtqueue *vq;
> > + int i, ret = 0;
> > +
> > + if (!vs->vs_tpg)
> > + return 0;
> > +
> > + for (i = VHOST_SCSI_VQ_IO; i < vs->dev.nvqs; i++) {
> > + vq = &vs->vqs[i].vq;
> > + mutex_lock(&vq->mutex);
> > + if (vhost_vq_get_backend(vq) || !vhost_vq_is_setup(vq))
> > + goto unlock;
> > +
> > + ret = vhost_scsi_setup_vq_cmds(vq, vq->num);
> > + if (ret)
> > + goto unlock;
> > +
> > + vhost_vq_set_backend(vq, vs->vs_tpg);
> > + ret = vhost_vq_init_access(vq);
> > + if (ret) {
> > + vhost_vq_set_backend(vq, NULL);
> > + vhost_scsi_destroy_vq_cmds(vq);
> > + }
> > +unlock:
> > + mutex_unlock(&vq->mutex);
> > + if (ret)
> > + break;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > /*
> > * Called from vhost_scsi_ioctl() context to walk the list of available
> > * vhost_scsi_tpg with an active struct vhost_scsi_nexus
> > @@ -2105,6 +2139,9 @@ vhost_scsi_set_endpoint(struct vhost_scsi *vs,
> >
> > for (i = 0; i < vs->dev.nvqs; i++) {
> > vq = &vs->vqs[i].vq;
> > + if (i >= VHOST_SCSI_VQ_IO && !vs->vqs[i].scsi_cmds)
> > + continue;
> > +
> > mutex_lock(&vq->mutex);>
> > vhost_vq_set_backend(vq, vs_tpg);
> > vhost_vq_init_access(vq);
> > @@ -2466,10 +2503,13 @@ vhost_scsi_ioctl(struct file *f,
> > default:
> > mutex_lock(&vs->dev.mutex);
> > r = vhost_dev_ioctl(&vs->dev, ioctl, argp);
> > - if (r == -ENOIOCTLCMD)
> > + if (r == -ENOIOCTLCMD) {
> > r = vhost_vring_ioctl(&vs->dev, ioctl, argp);
> > - else
> > + if (!r && ioctl == VHOST_SET_VRING_ADDR)
> > + r = vhost_scsi_activate_vqs(vs);
> Is it ok to just not support the delayed setup? So just do the
> fix in vhost_scsi_set_endpoint?
>
A later SET_VRING_ADDR would still succeed while leaving the queue
inactive. If we donot support it, I think it should fail explicitly
instead of causing a silent I/O stall.
> Is this a useful feature?
>
No current VMM appears to rely on it, but the UAPI does not specify this
ordering. A new VMM could reasonably use it.
> I don't think net supports it. When it does the vhost_net_set_backend
> call it does vhost_vq_access_ok. If it's not ready to go then it
> returns failure.
>
Right, net returns an error for that VQ. Simply skipping a scsi VQ would
make the later ioctl succeed without activating it.
> If we supported this, then I think vhost_scsi_activate_vqs should
> active the specific virtqueue that VHOST_SET_VRING_ADDR is called
> for.
Agreed. I will change it to activate only that virtqueue.
