From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <kostja.osipov@gmail.com>
Received: from mail-lf1-f68.google.com (mail-lf1-f68.google.com
 [209.85.167.68])
 (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 655C0469719
 for <tarantool-patches@dev.tarantool.org>;
 Fri, 14 Feb 2020 17:17:06 +0300 (MSK)
Received: by mail-lf1-f68.google.com with SMTP id n25so6884855lfl.0
 for <tarantool-patches@dev.tarantool.org>;
 Fri, 14 Feb 2020 06:17:06 -0800 (PST)
Date: Fri, 14 Feb 2020 17:17:04 +0300
From: Konstantin Osipov <kostja.osipov@gmail.com>
Message-ID: <20200214141704.GA10968@atlas>
References: <20200214132220.29830-1-gorcunov@gmail.com>
 <20200214132220.29830-3-gorcunov@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20200214132220.29830-3-gorcunov@gmail.com>
Subject: Re: [Tarantool-patches] [PATCH v8 2/2] fiber: leak slab if unable
 to bring prots back
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: Cyrill Gorcunov <gorcunov@gmail.com>
Cc: tml <tarantool-patches@dev.tarantool.org>, Vladislav Shpilevoy <v.shpilevoy@tarantool.org>

* Cyrill Gorcunov <gorcunov@gmail.com> [20/02/14 16:25]:
> In case if we unable to revert guard page back to
> read|write we should never use such slab again.
> 
> Initially I thought of just put panic here and
> exit but it is too destructive. I think better
> print an error and continue. If node admin ignore
> this message then one moment at future there won't
> be slab left for use and creating new fibers get
> prohibited.
> 
> In future (hopefully near one) we plan to drop
> guard pages to prevent VMA fracturing and use
> stack marks instead.

Seriously, let's have some decency, first we pushed an optional
feature and then it broke and you're suggestinga hot fix that leaks 
memory.

What's the issue with disabling the broken feature?


-- 
Konstantin Osipov, Moscow, Russia