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=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,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 8B41A1F8C8 for ; Fri, 17 Sep 2021 10:20:11 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 9DEC23858430 for ; Fri, 17 Sep 2021 10:20:10 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 9DEC23858430 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1631874010; bh=H9KdNJ7zcgeDaGu3os4UQzsoGS09SpRQsQuVCu87BLI=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=ZUV7rFpGxAow36QX1Z5xshqhzb/tKzIkDizipS3ps44rUcz1QRdfhYD4EhCQOiVY4 p/RyQwT+rGFzBGod97S81KHmP7f1fJ5wygswOYoNzqWe8Ck4yZnZbkBFs7YexwmqeP NZOY/E64VHsnAxD2HyK9gxDpw3ZI9LdWoJPQc/Ak= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id 7DCFD3858D29 for ; Fri, 17 Sep 2021 10:19:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7DCFD3858D29 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-279--HUqoz7yNB-IDmAq1xEOow-1; Fri, 17 Sep 2021 06:19:47 -0400 X-MC-Unique: -HUqoz7yNB-IDmAq1xEOow-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id A09CF801B3D; Fri, 17 Sep 2021 10:19:46 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.16]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 989D860BF1; Fri, 17 Sep 2021 10:19:44 +0000 (UTC) To: "H.J. Lu" Subject: Re: [PATCH v6 1/1] : An API for tagged address References: <20210822124546.154232-1-hjl.tools@gmail.com> <20210822124546.154232-2-hjl.tools@gmail.com> <87fsv0se5s.fsf@oldenburg.str.redhat.com> <874kbgp8y6.fsf@oldenburg.str.redhat.com> <20210903091231.GC21740@arm.com> <87k0ju13y4.fsf@oldenburg.str.redhat.com> Date: Fri, 17 Sep 2021 12:19:42 +0200 In-Reply-To: (H. J. Lu's message of "Mon, 6 Sep 2021 06:34:18 -0700") Message-ID: <87mtobec75.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: Szabolcs Nagy , GNU C Library , "Kirill A . Shutemov" , Joseph Myers Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" * H. J. Lu: > But I don't think we should add LAM to the list of the long-standing > issues. Without an API, we can never safely use LAM in glibc at > all. Yet you were able to backport it. >> Setting up LAM is just one more issue in a long list of things that can >> go wrong. And if LAM does not have an ABI impact, it can be backported, >> which would be nice. > > I backported it to glibc 2.33: > > [hjl@gnu-cfl-2 tmp]$ ar -t /lib64/libc_nonshared.a > elf-init.oS > atexit.oS > at_quick_exit.oS > pthread_atfork.oS > set-translated-address-mask.oS > stack_chk_fail_local.oS > [hjl@gnu-cfl-2 tmp]$ ar -x /lib64/libc_nonshared.a tagged-address.oS > set-translated-address-mask.oS > [hjl@gnu-cfl-2 tmp]$ nm set-translated-address-mask.oS > U errno > U _GLOBAL_OFFSET_TABLE_ > U _rtld_global > 0000000000000000 T set_translated_address_mask > U __stack_chk_fail_local > [hjl@gnu-cfl-2 tmp] > > At least, the same source can compile with glibc 2.33 and the > binary linked against glibc 2.33 will run with newer glibc. Why can't you do this while we experiment with HWSAN? >> Note that in glibc 2.34, we freed up DF_1_INITFIRST, so you could use >> that to set up things really early. > > What do you have in mind for LAM with DF_1_INITFIRST? How can it > address the LAM issues I have? It can make sure that the constructor runs as early as possible, so that the appropriate system calls are made before any thread creation. If the kernel interface does not provide coordination capabilities between different LAM consumers within the same process (even a minimal capability, like =E2=80=9Chas this been enabled yet?=E2=80=9D), that sounds= like a serious drawback. Thanks, Florian