netdev - RE: [PATCH] vdpa: allow vdpa dev_del management operation to return failure

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 for Android: free password hash cracker in your pocket

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

Date:   Sun, 12 Jun 2022 18:08:02 +0000
From:   Parav Pandit <parav@...dia.com>
To:     Jason Wang <jasowang@...hat.com>
CC:     "Dawar, Gautam" <gautam.dawar@....com>,
        netdev <netdev@...r.kernel.org>,
        "linux-net-drivers (AMD-Xilinx)" <linux-net-drivers@....com>,
        "Anand, Harpreet" <harpreet.anand@....com>,
        "Michael S. Tsirkin" <mst@...hat.com>,
        Zhu Lingshan <lingshan.zhu@...el.com>,
        Xie Yongji <xieyongji@...edance.com>,
        Eli Cohen <elic@...dia.com>,
        Si-Wei Liu <si-wei.liu@...cle.com>,
        Stefano Garzarella <sgarzare@...hat.com>,
        Wan Jiabing <wanjiabing@...o.com>,
        Dan Carpenter <dan.carpenter@...cle.com>,
        virtualization <virtualization@...ts.linux-foundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] vdpa: allow vdpa dev_del management operation to return
 failure



> From: Jason Wang <jasowang@...hat.com>
> Sent: Thursday, June 9, 2022 3:19 AM

[..]

> > > This is to avoid side-effects as noted in
> > > https://bugzilla.kernel.org/show_bug.cgi?id=213179 caused by
> > > deleting the vdpa device when it is being used.
> > > >
> > User should be able to delete the device anytime.
> 
> It requires a poll event to user space and then Qemu can release the vhost-
> vDPA device. This is how VFIO works. We probably need to implement
> something like this.
> 
Yes, I remember hang with either vfio or vfio-mdev.

> But notice that, at the worst case, usersapce may not respond to this event,
> so there's nothing more kenrel can do execpt for waiting.
> 
> We need to consider something different. I used to have an idea to make
> vhost-vdpa couple with vDPA loosely with SRCU/RCU. We might consider
> implementing that.
>
Right. It needs a different solution. As you described, vhost-vdpa cannot rely on the user space involvement in freeing.
Rdma uverbs does that for device removal cases to detach the user space ioctl() context with low level device.

> > Upper layers who are unable to perform teardown sequence should be
> fixed.
> 
> I think we probably don't need to bother with failing the dev_del().
> We can consider to fix/workaround the waiting first.
> 
Lets fix it as you hinted with S/RCU.
We don’t need to add UAPI for the fix.
UAPI anyway doesn’t work, when driver/system level event occurs such as device fatal error, sriov disablement, sf removal and more.
Vhost-vdpa should be able to detach it from the underlying device.