From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-3.7 required=3.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id EACF01F8C6 for ; Wed, 14 Jul 2021 12:54:34 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 30E6A398407F for ; Wed, 14 Jul 2021 12:54:32 +0000 (GMT) Received: from smtp4-g21.free.fr (smtp4-g21.free.fr [IPv6:2a01:e0c:1:1599::13]) by sourceware.org (Postfix) with ESMTPS id 4229D386103C; Wed, 14 Jul 2021 12:54:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 4229D386103C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=morinfr.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=morinfr.org Received: from bender.morinfr.org (unknown [82.64.86.27]) by smtp4-g21.free.fr (Postfix) with ESMTPS id CFDF919F5A9; Wed, 14 Jul 2021 14:54:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=morinfr.org ; s=20170427; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=ILSgqtaY98sUNvXjShlfv/FU8WZwAqBR83iayZ1Z/1U=; b=y9M3Hp4HThY1iL8Ao+TT42Ql1l eJOGcx7VxaM7TXzUyPpbjcluFYlCaRcV9HbM0+RmcjzK9+djLLlhyY9fYMuUef6rJ4RapWVmQi1e5 QzkIHQIre7w8ICN7fivbH8Hy5V8ZOuvbUSGs18t4/uVU355lObGYTSAbwaTMLkF9zFSA=; Received: from guillaum by bender.morinfr.org with local (Exim 4.92) (envelope-from ) id 1m3eP2-0006w1-EL; Wed, 14 Jul 2021 14:54:16 +0200 Date: Wed, 14 Jul 2021 14:54:16 +0200 From: Guillaume Morin To: Siddhesh Poyarekar Subject: Re: [PATCH v8 03/10] Remove __morecore and __default_morecore Message-ID: <20210714125415.GA24678@bender.morinfr.org> References: <20210713073845.504356-1-siddhesh@sourceware.org> <20210713073845.504356-4-siddhesh@sourceware.org> <9925362a-d278-a0ad-f504-ae08ca93f628@gotplt.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9925362a-d278-a0ad-f504-ae08ca93f628@gotplt.org> User-Agent: Mutt/1.10.1 (2018-07-13) X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: fweimer@redhat.com, Siddhesh Poyarekar , libc-alpha@sourceware.org, guillaume@morinfr.org Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On 14 Jul 12:31, Siddhesh Poyarekar wrote: > FYI, there's at least one use case[1] that is adversely affected by > __morecore removal. I have closed it as WONTFIX citing that malloc does not > always do the right thing with arbitrary morecore (and we don't even test > it) anyway and it's a net win to remove them, but I mention it here too in > the interest of a wider discussion. > > Guillaume, would you like to elaborate on the use case a bit more so that we > know exactly what we're dealing with? > > Siddhesh > > [1] https://sourceware.org/bugzilla/show_bug.cgi?id=20646 Hello Siddesh, I replied on the bug report becuase I had not seen this message. But basically, this breaks https://github.com/libhugetlbfs/libhugetlbfs/ which is old (started in 2006) and commonly used library. The library is plugging its own morecore() implementation to use hugetlb pages to back the malloc heap. This is definitely not a win for all libhugetlbfs users. We have no equivalent solution. You're asking to find us an entire new malloc implementation if there is one (or write one?). We have no way of keep using glibc's malloc and hugetlb. I am not even sure there exists an equivalent replacement. I understand there is some security concern about malloc hooks but then why not allow morecore() substitution with a properly documented/supported interface? Most users already LD_PRELOAD libhugetlbfs so that would be an easy fix. You're claiming that it's subtly broken. I'd like to understand how and why this can't be fixed. Afaik people have been using libhugetlbfs's morecore() in production for 15+ years without any issue. The only issue I am aware of is the one I reported about 5 years ago (along with a reproducer and a patch). This problem can only be reached if trimming is enabled in the morecore implementation (it's disabled in libhugetlbfs for this very reason). -- Guillaume Morin