From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gorcunov@gmail.com>
Received: from mail-lf1-f66.google.com (mail-lf1-f66.google.com
 [209.85.167.66])
 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 2473646970E
 for <tarantool-patches@dev.tarantool.org>;
 Wed,  5 Feb 2020 10:46:58 +0300 (MSK)
Received: by mail-lf1-f66.google.com with SMTP id c23so763142lfi.7
 for <tarantool-patches@dev.tarantool.org>;
 Tue, 04 Feb 2020 23:46:58 -0800 (PST)
Date: Wed, 5 Feb 2020 10:46:55 +0300
From: Cyrill Gorcunov <gorcunov@gmail.com>
Message-ID: <20200205074655.GH12445@uranus>
References: <20200128192249.10023-1-gorcunov@gmail.com>
 <20200128192249.10023-3-gorcunov@gmail.com>
 <20200203143928.GG547@tarantool.org> <20200204221556.GE20146@atlas>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200204221556.GE20146@atlas>
Subject: Re: [Tarantool-patches] [PATCH v7 2/5] box/applier: add missing
 diag_set on region_alloc failure
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: Konstantin Osipov <kostja.osipov@gmail.com>
Cc: tml <tarantool-patches@dev.tarantool.org>

On Wed, Feb 05, 2020 at 01:15:56AM +0300, Konstantin Osipov wrote:
> * Sergey Ostanevich <sergos@tarantool.org> [20/02/03 17:42]:
> > Hi!
> > 
> > Thanks for the patch!
> > 
> > LGTM.
> 
> This code is dead actually. There is no region quota and OOM is
> impossible here. We haven't had a policy to check these errors
> before. 
> 
> No harm in pushing it, but no value either.

Wait, region_alloc (as other slab related functions) are using
malloc call on low level (see slab_get_large) thus there is
no guarantee that NULL won't be ever returned, moreover malloc
interface never claimed that NULL will be returned iif there
no free memory in the system (actually this is not how malloc
works now but api points explicitly that we should be ready
for NULL and handle it properly).

IOW I think we should handle NULLs to be stable in long terms.