The Wednesday 28 May 2014 à 16:37:41 (+0200), Kevin Wolf wrote :
> Some code in the block layer makes potentially huge allocations. Failure
> is not completely unexpected there, so avoid aborting qemu and handle
> out-of-memory situations gracefully.
>
> This patch addresses the allocations in the nfs block driver.
>
> Signed-off-by: Kevin Wolf <kw...@redhat.com>
> Reviewed-by: Stefan Hajnoczi <stefa...@redhat.com>
> ---
> block/nfs.c | 6 +++++-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/block/nfs.c b/block/nfs.c
> index 539bd95..e3d6216 100644
> --- a/block/nfs.c
> +++ b/block/nfs.c
> @@ -165,7 +165,11 @@ static int coroutine_fn nfs_co_writev(BlockDriverState
> *bs,
>
> nfs_co_init_task(client, &task);
>
> - buf = g_malloc(nb_sectors * BDRV_SECTOR_SIZE);
Just wondering.
I see nothing in brv_write preventing write of nb_sectors == 0.
g_malloc return NULLL on zero allocation. If g_try_malloc behave the same this
case would make a spurious -ENOMEM report when a write of size 0 is done.
> + buf = g_try_malloc(nb_sectors * BDRV_SECTOR_SIZE);
> + if (buf == NULL) {
> + return -ENOMEM;
> + }
> +
> qemu_iovec_to_buf(iov, 0, buf, nb_sectors * BDRV_SECTOR_SIZE);
>
> if (nfs_pwrite_async(client->context, client->fh,
> --
> 1.8.3.1
>
>
