| Message ID | 1401287873-25805-9-git-send-email-kwolf@redhat.com |
|---|---|
| State | New |
| Headers | show |
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 <kwolf@redhat.com> > Reviewed-by: Stefan Hajnoczi <stefanha@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 > >
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); + 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,