Re: [PATCH] virtio: Don't access index after unregister.

[Michael S. Tsirkin]

On Thu, Nov 08, 2012 at 11:43:47AM +0100, Cornelia Huck wrote:
> Virtio wants to release used indices after the corresponding
> virtio device has been unregistered. However, virtio does not
> hold an extra reference, giving up its last reference with
> device_unregister(), making accessing dev->index afterwards
> invalid.
> 
> I actually saw problems when testing my (not-yet-merged)
> virtio-ccw code:
> 
> - device_add virtio-net,id=xxx
> -> creates device virtio<n> with n>0
> 
> - device_del xxx
> -> deletes virtio<n>, but calls ida_simple_remove with an
>    index of 0
> 
> - device_add virtio-net,id=xxx
> -> tries to add virtio0, which is still in use...
> 
> So let's save the index we want to release before calling
> device_unregister().
> 
> Signed-off-by: Cornelia Huck <cornelia.huck@xxxxxxxxxx>
> ---
>  drivers/virtio/virtio.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/virtio/virtio.c b/drivers/virtio/virtio.c
> index 1e8659c..809b0de 100644
> --- a/drivers/virtio/virtio.c
> +++ b/drivers/virtio/virtio.c
> @@ -225,8 +225,10 @@ EXPORT_SYMBOL_GPL(register_virtio_device);
>  
>  void unregister_virtio_device(struct virtio_device *dev)
>  {
> +	int index = dev->index; /* save for after device release */

It's obvious from code that we safe for after release,
I think a better comment would explain *why* we do this.

Something like
	/*
	   device_unregister drops reference to device so put_device could
	   invoke release callback. In case that callback will free the device,
	   make sure we don't access device after this call.
	 */
   	int index = dev->index;

?

> +
>  	device_unregister(&dev->dev);
> -	ida_simple_remove(&virtio_index_ida, dev->index);
> +	ida_simple_remove(&virtio_index_ida, index);
>  }
>  EXPORT_SYMBOL_GPL(unregister_virtio_device);
>  
> -- 
> 1.7.12.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/