From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 2655D3853D1B for ; Fri, 7 Jul 2023 14:55:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2655D3853D1B Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1688741747; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=ItYFMDmKw+E65mHFNbNfYhJ5MgU43VFAHmm0E+eVOFY=; b=AerH8h2uYsOW9l9t6v5ihxCn37CSnkQlETgePLzzEsLUCIZ+Z26ZwKgeudVkrvel9hZS/A 6HBMEUy8wHRPY6vMKlti6DUiUx9sm11w1ppxShN29iRx4LVt49eU+CgEPN99F8tvP3sy2b GDik+gxqyqmYXJ4ifV0PoIXNYwnmdu4= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-292-QzBtb_20M6uAKAAR10aKSw-1; Fri, 07 Jul 2023 10:55:46 -0400 X-MC-Unique: QzBtb_20M6uAKAAR10aKSw-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id AA84C803FDF; Fri, 7 Jul 2023 14:55:43 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.2.16.31]) by smtp.corp.redhat.com (Postfix) with ESMTPS id B3F9D4087C6A; Fri, 7 Jul 2023 14:55:42 +0000 (UTC) From: Florian Weimer To: Adhemerval Zanella Netto Cc: Carlos O'Donell , Maxim Kuvyrkov , libc-alpha@sourceware.org Subject: Re: [PATCH 00/33] RFC: RELRO link maps References: <874jmjwid9.fsf@oldenburg.str.redhat.com> <741d667e-818e-1552-a496-7d6bb1212313@redhat.com> <87edlmfj17.fsf@oldenburg.str.redhat.com> <873520geot.fsf@oldenburg.str.redhat.com> <87pm53gafm.fsf@oldenburg.str.redhat.com> <9495eead-7153-82dc-ccf8-7e5ff089ba40@linaro.org> <87h6qfg8rg.fsf@oldenburg.str.redhat.com> Date: Fri, 07 Jul 2023 16:55:40 +0200 In-Reply-To: (Adhemerval Zanella Netto's message of "Fri, 7 Jul 2023 10:58:28 -0300") Message-ID: <87351zg49f.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-3.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Adhemerval Zanella Netto: > Alright, I will check again once you repost it. I have not look this > series in detail, but I wonder if you could split in first adding the > dlopen hash speedup and then add the hardening, as two different sets. > I am not sure how hard or if it would be feasible. The struct link_map_private change conflicts to some degree. But having the protected memory allocator really simplifies two things: we no longer have to worry about switching from the minimal malloc to the libc.so malloc. It's always the protected memory allocator, so _dl_protmem_free works during early startup and once user code starts running. The other thing is that valgrind and mtrace do not see the allocations, so we don't need to free them. I alluded this in the cover letter; I think we should add something to report leaked memory based on tracing from the data structure roots, rather than figuring out a safe way how to deallocate things during process shutdown. Thanks, Florian