[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [Fwd: [PATCH v4 07/21] iscsi: Handle failure for potent
From: |
Peter Lieven |
Subject: |
Re: [Qemu-devel] [Fwd: [PATCH v4 07/21] iscsi: Handle failure for potentially large allocations] |
Date: |
Fri, 22 Aug 2014 10:59:13 +0200 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 |
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 <address@hidden>
>>> Acked-by: Paolo Bonzini <address@hidden>
>>> Reviewed-by: Benoit Canet <address@hidden>
>>> Reviewed-by: Eric Blake <address@hidden>
>>> ---
>>> 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