linux-kernel - Re: [PATCH v11 12/12] vduse: bump version number

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAJaqyWfE3j9B-66Bha2xAvudgWprpkLP9rjxHUkGPJhznujybw@mail.gmail.com>
Date: Tue, 13 Jan 2026 16:09:20 +0100
From: Eugenio Perez Martin <eperezma@...hat.com>
To: Jason Wang <jasowang@...hat.com>
Cc: "Michael S . Tsirkin" <mst@...hat.com>, linux-kernel@...r.kernel.org, 
	virtualization@...ts.linux.dev, Maxime Coquelin <mcoqueli@...hat.com>, 
	Laurent Vivier <lvivier@...hat.com>, Cindy Lu <lulu@...hat.com>, 
	Xuan Zhuo <xuanzhuo@...ux.alibaba.com>, Stefano Garzarella <sgarzare@...hat.com>, 
	Yongji Xie <xieyongji@...edance.com>
Subject: Re: [PATCH v11 12/12] vduse: bump version number

On Tue, Jan 13, 2026 at 7:25 AM Jason Wang <jasowang@...hat.com> wrote:
>
> On Fri, Jan 9, 2026 at 11:25 PM Eugenio Pérez <eperezma@...hat.com> wrote:
> >
> > Finalize the series by advertising VDUSE API v1 support to userspace.
> >
> > Now that all required infrastructure for v1 (ASIDs, VQ groups,
> > update_iotlb_v2) is in place, VDUSE devices can opt in to the new
> > features.
> >
> > Acked-by: Jason Wang <jasowang@...hat.com>
> > Reviewed-by: Xie Yongji <xieyongji@...edance.com>
> > Signed-off-by: Eugenio Pérez <eperezma@...hat.com>
> > ---
> >  drivers/vdpa/vdpa_user/vduse_dev.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/vdpa/vdpa_user/vduse_dev.c b/drivers/vdpa/vdpa_user/vduse_dev.c
> > index 8227b5e9f3f6..5ad0ba1392f3 100644
> > --- a/drivers/vdpa/vdpa_user/vduse_dev.c
> > +++ b/drivers/vdpa/vdpa_user/vduse_dev.c
> > @@ -2201,7 +2201,7 @@ static long vduse_ioctl(struct file *file, unsigned int cmd,
> >                         break;
> >
> >                 ret = -EINVAL;
> > -               if (api_version > VDUSE_API_VERSION)
> > +               if (api_version > VDUSE_API_VERSION_1)
> >                         break;
> >
> >                 ret = 0;
> > @@ -2268,7 +2268,7 @@ static int vduse_open(struct inode *inode, struct file *file)
> >         if (!control)
> >                 return -ENOMEM;
> >
> > -       control->api_version = VDUSE_API_VERSION;
> > +       control->api_version = VDUSE_API_VERSION_1;
>
> This can break the "legacy" userspace that doesn't call VDUSE_SET_API_VERSION?
>
> Thanks
>

It can result in a userland visible change, yes. Protecting it for the
next version, thanks for pointing it out!

I don't think you can "break" any valid userspace VDUSE actually, the
only change the userland VDUSE can see is if calls
VDUSE_IOTLB_GET_FD2, set the vq group in VDUSE_VQ_SETUP, set the asid
in VDUSE_IOTLB_GET_INFO, or similar. In that case, the userland device
gets -ENOIOCTLCMD or -EINVAL and suddenly something "valid" happens if
the kernel applies this patch. But it is an userland visible change
anyway, so I'll protect it for the next version.

Thanks!