On 02/13/2014 05:45 PM, Michael S. Tsirkin wrote:
> vhost_zerocopy_callback accesses VQ right after it drops a ubuf
> reference.  In theory, this could race with device removal which waits
> on the ubuf kref, and crash on use after free.
>
> Do all accesses within rcu read side critical section, and synchronize
> on release.
>
> Since callbacks are always invoked from bh, synchronize_rcu_bh seems
> enough and will help release complete a bit faster.
>
> Signed-off-by: Michael S. Tsirkin <[email protected]>
> ---
>
> This is was previously posted as part of patch
> series, but it's an independent fix really.
> Theoretical race so not needed for stable I think.
>
> changes from v1:
>       fixed typo in commit log
>
>  drivers/vhost/net.c | 6 ++++++
>  1 file changed, 6 insertions(+)
>
> diff --git a/drivers/vhost/net.c b/drivers/vhost/net.c
> index b12176f..f1be80d 100644
> --- a/drivers/vhost/net.c
> +++ b/drivers/vhost/net.c
> @@ -308,6 +308,8 @@ static void vhost_zerocopy_callback(struct ubuf_info 
> *ubuf, bool success)
>       struct vhost_virtqueue *vq = ubufs->vq;
>       int cnt;
>  
> +     rcu_read_lock_bh();
> +
>       /* set len to mark this desc buffers done DMA */
>       vq->heads[ubuf->desc].len = success ?
>               VHOST_DMA_DONE_LEN : VHOST_DMA_FAILED_LEN;
> @@ -322,6 +324,8 @@ static void vhost_zerocopy_callback(struct ubuf_info 
> *ubuf, bool success)
>        */
>       if (cnt <= 1 || !(cnt % 16))
>               vhost_poll_queue(&vq->poll);
> +
> +     rcu_read_unlock_bh();
>  }
>  
>  /* Expects to be always run from workqueue - which acts as
> @@ -804,6 +808,8 @@ static int vhost_net_release(struct inode *inode, struct 
> file *f)
>               fput(tx_sock->file);
>       if (rx_sock)
>               fput(rx_sock->file);
> +     /* Make sure no callbacks are outstanding */
> +     synchronize_rcu_bh();
>       /* We do an extra flush before freeing memory,
>        * since jobs can re-queue themselves. */
>       vhost_net_flush(n);

Acked-by: Jason Wang <[email protected]>
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to