From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by sourceware.org (Postfix) with ESMTPS id 3B0FE3858D1E for ; Mon, 1 May 2023 23:12:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 3B0FE3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=owlfolio.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=owlfolio.org Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 331665C0126; Mon, 1 May 2023 19:12:07 -0400 (EDT) Received: from imap45 ([10.202.2.95]) by compute1.internal (MEProxy); Mon, 01 May 2023 19:12:07 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=owlfolio.org; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1682982727; x=1683069127; bh=hwrUAreQsZ7oorHpyik4E3Oyz4qzZK5jCWS d9SRAtJ4=; b=qRQb+92fn+Y/mQ3Gm6622bh6aWk1MP7GT8lXo78MvWKyd8RFp3g d97L54j8dkQopPFG8nxlJBXWcFDVSFPwVdl6GPhWU9t6Ze21CSN19nHcj8bvBXgC WfH1r8qos2rQ1hHu9jeJVeEVRXP51JURKMD8TkDZm0THcPQj0ZrEwHtm2++LSBoo 5a3fUE0XYmORTo2pgq7v/yeTpkWdhXVDc1SNAFi/TvKliH23qUHlHQwGb0Fwrw7i pvh6mMTppp9zIVNRodZ263WST7Jud++uTLOKjCGNB4kEmzJf7rhj5qjs8rkvff1Y l/+wqeCGL2os+qzsfT5gW/1ExzcT0qAoXfw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1682982727; x=1683069127; bh=hwrUAreQsZ7oorHpyik4E3Oyz4qzZK5jCWS d9SRAtJ4=; b=ZJ89smYceEfQHWAEwkr2LexHaRPX8+T4A5Hx3K6KxpGFQ/SOFte qe/ENywh09g1Tad1FG79hwCz86LcQkEbXdijgRwjKgungW702tQ1b3Qm6x7SglEq SOv8fThw8XHO/uc8htYyB8p2rPbunH84QPhCMHX7TO2e0kY+u8gsdv3yuyhqq1ze Zru2ZST5w7nymV5wquTMmj0jrmpJ4Gbb/6fjbzvaAkwJ/F00XxVWQy9EFBd0ysJ1 BNzEtsY8+S8Nv+No8yHcenFdUnJxTbsAx4to6NQIKE44lFzpx5r2eGoJdo6ucBHw VKyrgCh5kQYHKpktRRjQ7jts7vwJOd8DjOg== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfedvhedgudelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvfevufgtgfesthhqredtreerjeenucfhrhhomhepfdgk rggtkhcuhggvihhnsggvrhhgfdcuoeiirggtkhesohiflhhfohhlihhordhorhhgqeenuc ggtffrrghtthgvrhhnpeduueeigeehffekiefhtdehiedvueffteevtefhudfguedtueei tdetgfetieeiieenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpeiirggtkhesohiflhhfohhlihhordhorhhg X-ME-Proxy: Feedback-ID: i876146a2:Fastmail Received: by mailuser.nyi.internal (Postfix, from userid 501) id DF949272007A; Mon, 1 May 2023 19:12:06 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.9.0-alpha0-374-g72c94f7a42-fm-20230417.001-g72c94f7a Mime-Version: 1.0 Message-Id: <598d5c35-86dd-4731-8099-4165bff514db@app.fastmail.com> In-Reply-To: <3f636504-818d-6520-6cf3-484503a8703c@yandex.ru> References: <298b04a6-3055-b89b-59c1-4cfbe955848e@yandex.ru> <81749d04-8cdb-de0b-b88e-24347ed535ba@yandex.ru> <729710b5-6dae-d5f2-99ee-6923be5e627d@yandex.ru> <20230412182043.GI3298@brightrain.aerifal.cx> <08d9ca95-112c-d85e-8e82-7a595ef4d051@yandex.ru> <78b5b5dc-5657-4bf8-24c6-6c00afb1cc40@yandex.ru> <83ee7b42-7a50-e8d1-e9ca-58ec2a12a995@linaro.org> <59862084-0fe3-7642-d3b3-01bb87eef7db@yandex.ru> <52d0b5e8-2c81-66e6-60dc-771d01b26fd6@linaro.org> <3f636504-818d-6520-6cf3-484503a8703c@yandex.ru> Date: Mon, 01 May 2023 19:11:45 -0400 From: "Zack Weinberg" To: stsp Cc: "GNU libc development" , "Adhemerval Zanella" , "Carlos O'Donell" Subject: Re: proof for dlmem() (Re: [PATCH v9 0/13] implement dlmem() function) Content-Type: text/plain;charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,JMQ_SPF_NEUTRAL,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: This discussion seems to have died down in the past two weeks but I'm going to make one last attempt to bridge the divide. I would hate to see everyone walk away from this with a bad taste in their mouth. Note cc: list aggressively pruned. On Fri, Apr 14, 2023, at 3:04 PM, stsp via Libc-alpha wrote: > 14.04.2023 01:02, Adhemerval Zanella Netto =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: >> "It would be possible to require the caller to arrange all of these >> things, but that's basically offloading A LOT of the ELF loading >> process onto the calling program and I don't think that makes for a >> reasonable public interface for glibc to provide." > OK, in this case I am going to provide a very detailed, reproducible > and undisputable proof that the above quote is false. Here's the thing: stsp, no one is intentionally trying to spread lies about your patch. You have misunderstood Adhemerval here. He was *not* saying that *your patch* required the caller to parse ELF headers themselves. He was saying that your patch does a *different* unacceptable thing -- running user-supplied code with the loader lock held, if I understood correctly -- and then he was trying to warn you that any *alternative* patch you might come up with would *also* be unacceptable if it required the caller to parse the DLL themselves. Do you understand the difference between what you thought Adhemerval was saying, and what I am saying he was trying to communicate? Please confirm, or else describe why you don't see a difference so I can try to clarify again. Now. Another thing you must understand before you send in any further revisions of the patch is that glibc is extremely reluctant to add new APIs. Witness how much we resisted adding strlcpy, a single function with a clear specification and no interdependencies with any other part of the C library. This is why you are getting what probably seems to you like an absurd level of negative feedback. We aren't trying to deny that you have a legitimate need, and we aren't saying you haven't managed to come up with a proof of concept implementation of how that need could be solved -- and yet we ARE saying, no, still not good enough. We do this because once we add something, we are stuck with it *forever*. Not even if the C committee itself deletes something from the standard do we drop it. You can *still*, today, write a new program that uses gets(). And we also do this because GNU libc is loaded into the address space of *every program* running on (GNU/)Linux. You're asking to take up a chunk of (virtual) RAM in *every program* in order to make your one specific program simpler. This *will* make at least a few programs' L1 cache utilization worse. Not by much, but this happens every time we add something and it adds up. --- Having said all that, I can imagine other uses for dlmem() or something = like it, besides your specific program, so let me try to meet you in the= middle here. Suppose we gave you *this* API: /** Report the total amount of virtual address space required in order t= o load * the shared object referred to by FD. FD must be a readable and seek= able * file descriptor. Returns a whole number of pages, or zero on error * (in which case errno will provide details). */ size_t dl_total_vsize(int fd); /** Load the shared object referred to by FD into this process's address * space. FD must be a readable and seekable file descriptor. * * If LOAD_ADDR is not NULL, it specifies the address at which to load * the shared object. If this is not possible, for instance if there * are already memory mappings in the range from LOAD_ADDR to LOAD_ADDR * plus dl_total_vsize(FD), the operation will fail. LOAD_ADDR must be * a multiple of the system page size. * * MODE accepts the same set of RTLD_* flags as are documented for dlop= en(), * plus one more: RTLD_READ directs the dynamic loader to read the shar= ed * object into the process's address space as-if with read() rather than * with mmap(). When this flag is used, LOAD_ADDR may not be NULL, and= must * already point to at least dl_total_vsize(FD) bytes of writable memor= y. * The dynamic loader will take ownership of that range of addresses and * may subsequently (e.g. upon a call to dlclose()) deallocate them as-= if * with munmap(). Furthermore, the dynamic loader will change virtual * memory protection settings for sub-ranges of this space, so that * (for instance) the text segment of the shared object is read-only, * as-if by calling mprotect(). */ void *dl_fdopen(int fd, int mode, void *load_addr); What would still be missing for your use case? zw