From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oa1-x2d.google.com (mail-oa1-x2d.google.com [IPv6:2001:4860:4864:20::2d]) by sourceware.org (Postfix) with ESMTPS id DDD5E3858D1E for ; Wed, 29 Mar 2023 12:32:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org DDD5E3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=linaro.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=linaro.org Received: by mail-oa1-x2d.google.com with SMTP id 586e51a60fabf-17786581fe1so16002109fac.10 for ; Wed, 29 Mar 2023 05:32:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; t=1680093171; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=/G6GWZ/9rfZh0tR0TruWSyUAdrxDWfslkqd7EQAZzk4=; b=wkklsShOgZ+VVTM3hVcVLaFlkGlIN+q2e9GwD1AH5A0GFGiDRVP0dMM6qVFgVLBuoO stNI8pIyE2CgkGxk1Hk9Bhn+e9LKoJwjU+tb/Bk1APdIpKTJjbovRHJcAOSRBykQnowx 6HDpGdVTLS0m+RBMHgTTnDCXDDXUn3wXzwfJdqMPK2v/h7XrU0s9O/ceT8dbN+4nwlhX ZTHud3WTlOfQ2nelRkMMw8Qr6lpjbfvxmKmvsouzDx707jyO2qYKvLfwVMEwEhsTmsX/ 1EA8aCc96XB7dIkGuO5yBU3AgKiE9j+5GoQtHsXDafzud5MISCOlEf68wmYx9kJ//0TT tUVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680093171; h=content-transfer-encoding:in-reply-to:organization:from:references :to:content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=/G6GWZ/9rfZh0tR0TruWSyUAdrxDWfslkqd7EQAZzk4=; b=mpWChnIHxrxh2a+kjZ2lEeJlhQkJgJVL5TW0R6hp59pXsI9vVJMKr0ddncD47S6N9+ V9WSmtiLiGaVCexooQFzOVnstMXiBy89hQ2NWF1v2dGR6KHU9XT71uEcOTJjS87uuPq1 BDp+dRLENwIbWJCMiBchHCugMfaFy8Aj2YK6YJLCyTgU5p/QHEBf6WShjiFN+77GlGEL 3PSD0RYnzw0jf2ty5yHmqF2ObiLtZNIl+CaioWpymTnr+yS5l77CF9UrU2uP+nkTufG1 +Bm/n/kBJyk8oWgYWoj/2rSMCT9edux1j+PRBCzoHT2aVtZQk7FNqRyJZDzhyd1XI2+l /JQA== X-Gm-Message-State: AAQBX9fKWXC/QksGt1lunK2esoCBFHtEK7SIQUMA2TNQ2iPki6AgDhN3 8Chjyeb8A4boQ3cbS3G2MTjosA== X-Google-Smtp-Source: AKy350bKXI39pB9Ib97/SeTJnKAbcp/niB004UBGR7E8P5zwZ9NBfHXRkpytlic1AKRKix+9PHTsXg== X-Received: by 2002:a05:6870:ec8c:b0:17a:bf1b:cab8 with SMTP id eo12-20020a056870ec8c00b0017abf1bcab8mr12306267oab.4.1680093171123; Wed, 29 Mar 2023 05:32:51 -0700 (PDT) Received: from ?IPV6:2804:1b3:a7c1:60f9:1426:1d2d:d6b:1761? ([2804:1b3:a7c1:60f9:1426:1d2d:d6b:1761]) by smtp.gmail.com with ESMTPSA id du18-20020a0568703a1200b001727c3bf124sm11217900oab.31.2023.03.29.05.32.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 29 Mar 2023 05:32:50 -0700 (PDT) Message-ID: Date: Wed, 29 Mar 2023 09:32:47 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.9.0 Subject: Re: [PATCH v9 0/13] implement dlmem() function Content-Language: en-US To: Stas Sergeev , libc-alpha@sourceware.org, janderson@rice.edu, Carlos O'Donell , Rich Felker References: <20230318165110.3672749-1-stsp2@yandex.ru> From: Adhemerval Zanella Netto Organization: Linaro In-Reply-To: <20230318165110.3672749-1-stsp2@yandex.ru> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,NICE_REPLY_A,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 18/03/23 13:50, Stas Sergeev via Libc-alpha wrote: > Changes in v9: > - use "zero-copy" machinery instead of memcpy(). It works on linux 5.13 > and newer, falling back to memcpy() otherwise. Suggested by Florian Weimer. > - implement fdlopen() using the above functionality. It is in a new test > tst-dlmem-fdlopen. Suggested by Carlos O'Donell. > - add DLMEM_DONTREPLACE flag that doesn't replace the backing-store mapping. > It switches back to memcpy(). Test-case is called tst-dlmem-shm. Hi Stas, This discussion has been dragging without much conclusion while you have sent multiple iterations of the same proposal without addressing the initial issues Carlos, Jonathan, and myself have raised. I will not focus on your specific usercase since it is quite singular and I think will not be applicable to a libc interface (mapping a VM memory with different bit size and gluing all together should be an application domain instead of bleeding out the interface to the libc). Jonathan already summarized the main issue with dlmem: - dlmem() seems to to expect the user to parse the program headers and mmap() the binary as required. That requires the application to re-implement a core, delicate piece of ld.so... and do so correctly. From an API design perspective, that seems like a very poor choice of abstraction. As well Carlos: * No guarantee that the memory that is loaded meets the preconditions for the dynamic loader and application uses. And this alone seems to me that this interface is not easily composable and adds a lot of corner cases if the user does not provide an expected ELF image. This is in par of what Carlos has raised [1] and IMHO you have not addresses the issues, since you have focused on how this interface applies to your specific problem instead of see who it fits as a generic libc interface (I will let Carlos comment further). As a generic interface I also don't see how this would really fit, it means that process need to map a memory segment that was generated either through a JIT or through an external process that can not provide a named file access (due security limitation). For these a fdlopen similar to BSD makes more sense: for former memfd_create can be used, while for later either shm_open or passing the fd through unix sockets. So I don't think dlmem really fits on glibc, although I might take a loot on the internal code refactoring. I am ccing Rich Felker, creator of musl libc, since he might have some additional insights whether this interface make sense or not (and he usually have good ones). [1] https://sourceware.org/pipermail/libc-alpha/2023-February/145735.html