linux-kernel - Re: [RFC PATCH 13/15] virtio-mem: Handle virtio_device

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

Date:   Mon, 17 May 2021 11:48:33 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Xie Yongji <xieyongji@...edance.com>, mst@...hat.com,
        jasowang@...hat.com, stefanha@...hat.com
Cc:     amit@...nel.org, arei.gonglei@...wei.com, airlied@...ux.ie,
        kraxel@...hat.com, jean-philippe@...aro.org, ohad@...ery.com,
        bjorn.andersson@...aro.org, vgoyal@...hat.com, miklos@...redi.hu,
        lucho@...kov.net, asmadeus@...ewreck.org,
        virtualization@...ts.linux-foundation.org,
        linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 13/15] virtio-mem: Handle virtio_device_ready()
 failure

On 17.05.21 11:34, Xie Yongji wrote:
> Now virtio_device_ready() will return error if we get
> invalid status. Let's handle this case on probe.
> 
> Signed-off-by: Xie Yongji <xieyongji@...edance.com>
> ---
>   drivers/virtio/virtio_mem.c | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/virtio/virtio_mem.c b/drivers/virtio/virtio_mem.c
> index 32a8e359a5c3..1148c392ff94 100644
> --- a/drivers/virtio/virtio_mem.c
> +++ b/drivers/virtio/virtio_mem.c
> @@ -2602,13 +2602,17 @@ static int virtio_mem_probe(struct virtio_device *vdev)
>   	if (rc)
>   		goto out_unreg_mem;
>   
> -	virtio_device_ready(vdev);
> +	rc = virtio_device_ready(vdev);
> +	if (rc)
> +		goto out_unreg_device;
>   
>   	/* trigger a config update to start processing the requested_size */
>   	atomic_set(&vm->config_changed, 1);
>   	queue_work(system_freezable_wq, &vm->wq);
>   
>   	return 0;
> +out_unreg_device:
> +	unregister_virtio_mem_device(vm);
>   out_unreg_mem:
>   	unregister_memory_notifier(&vm->memory_notifier);
>   out_del_resource:
> 

I assume this will really be a corner case to hit, right?


Failing after essentially being done initializing looks sub-optimal, anyhow:

Acked-by: David Hildenbrand <david@...hat.com>

-- 
Thanks,

David / dhildenb