From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36850) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKkgv-0008PM-3M for qemu-devel@nongnu.org; Fri, 22 Aug 2014 04:59:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XKkgp-0003oK-26 for qemu-devel@nongnu.org; Fri, 22 Aug 2014 04:59:25 -0400 Received: from mx-v6.kamp.de ([2a02:248:0:51::16]:51030 helo=mx01.kamp.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XKkgo-0003o0-OC for qemu-devel@nongnu.org; Fri, 22 Aug 2014 04:59:18 -0400 Message-ID: <53F70661.7080001@kamp.de> Date: Fri, 22 Aug 2014 10:59:13 +0200 From: Peter Lieven MIME-Version: 1.0 References: <00c425bd67fc66567dc683205f8f60f7.squirrel@ssl.dlhnet.de> <53F6F3DD.2090804@kamp.de> <20140822084246.GA32377@noname.redhat.com> In-Reply-To: <20140822084246.GA32377@noname.redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [Fwd: [PATCH v4 07/21] iscsi: Handle failure for potentially large allocations] List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: benoit.canet@irqsave.net, Paolo Bonzini , maxa@catit.be, qemu-devel@nongnu.org, stefanha@redhat.com Am 22.08.2014 um 10:42 schrieb Kevin Wolf: > Am 22.08.2014 um 09:40 hat Peter Lieven geschrieben: >> Am 22.08.2014 um 09:35 schrieb Peter Lieven: >>> 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 iscsi block driver. >>> >>> Signed-off-by: Kevin Wolf >>> Acked-by: Paolo Bonzini >>> Reviewed-by: Benoit Canet >>> Reviewed-by: Eric Blake >>> --- >>> block/iscsi.c | 5 ++++- >>> 1 file changed, 4 insertions(+), 1 deletion(-) >>> >>> diff --git a/block/iscsi.c b/block/iscsi.c >>> index 84aa22a..06afa78 100644 >>> --- a/block/iscsi.c >>> +++ b/block/iscsi.c >>> @@ -893,7 +893,10 @@ coroutine_fn iscsi_co_write_zeroes(BlockDriverState >>> *bs, int64_t sector_num, >>> nb_blocks = sector_qemu2lun(nb_sectors, iscsilun); >>> >>> if (iscsilun->zeroblock == NULL) { >>> - iscsilun->zeroblock = g_malloc0(iscsilun->block_size); >>> + iscsilun->zeroblock = g_try_malloc0(iscsilun->block_size); >>> + if (iscsilun->zeroblock == NULL) { >>> + return -ENOMEM; >>> + } >>> } >>> >>> iscsi_co_init_iscsitask(iscsilun, &iTask); >> Unfortunately, I missed that one. The zeroblock is typicalls 512 Byte or 4K depending >> on the blocksize. > I don't remember the details, but I think when I went through all > drivers, I couldn't convince myself that a reasonable block size is > enforced somewhere. So I just went ahead and converted the call to be on > the safe side. It can never hurt anyway. > >> What is significantly larger is the allocationmap. It is typically created >> on iscsi_open, but is also recreated on iscsi_truncate. I don't have the context why this >> patch was introduced, but I would vote for introducing a bitmap_try_new and issue >> a warning if the allocation fails. The allocationmap is optional we can work without it. >> If the pointer is NULL its not used. > Right, that one I missed because it doesn't directly use g_malloc(). > > Your proposal sounds good to me. Are you going to prepare a patch? will do. Peter