netdev - Re: Question about IRQs during the .remove() of virtio-vsock driver

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20190521055650-mutt-send-email-mst@kernel.org>
Date:   Tue, 21 May 2019 06:05:31 -0400
From:   "Michael S. Tsirkin" <mst@...hat.com>
To:     Stefano Garzarella <sgarzare@...hat.com>
Cc:     Jason Wang <jasowang@...hat.com>, netdev@...r.kernel.org,
        Stefan Hajnoczi <stefanha@...hat.com>
Subject: Re: Question about IRQs during the .remove() of virtio-vsock driver

On Tue, May 21, 2019 at 11:44:07AM +0200, Stefano Garzarella wrote:
> Hi Micheal, Jason,
> as suggested by Stefan, I'm checking if we have some races in the
> virtio-vsock driver. We found some races in the .probe() and .remove()
> with the upper layer (socket) and I'll fix it.
> 
> Now my attention is on the bottom layer (virtio device) and my question is:
> during the .remove() of virtio-vsock driver (virtio_vsock_remove), could happen
> that an IRQ comes and one of our callback (e.g. virtio_vsock_rx_done()) is
> executed, queueing new works?
> 
> I tried to follow the code in both cases (device unplugged or module removed)
> and maybe it couldn't happen because we remove it from bus's knowledge,
> but I'm not sure and your advice would be very helpful.
> 
> Thanks in advance,
> Stefano


Great question! This should be better documented: patches welcome!

Here's my understanding:


A typical removal flow works like this:

- prevent linux from sending new kick requests to device
  and flush such outstanding requests if any
  (device can still send notifications to linux)

- call
          vi->vdev->config->reset(vi->vdev);
  this will flush all device writes and interrupts.
  device will not use any more buffers.
  previously outstanding callbacks might still be active.

- Then call
          vdev->config->del_vqs(vdev);
  to flush outstanding callbacks if any.

-- 
MST