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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.7 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RDNS_DYNAMIC,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (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 CF15D1F8C6 for ; Mon, 23 Aug 2021 09:29:17 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A80433857C6B for ; Mon, 23 Aug 2021 09:29:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A80433857C6B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629710956; bh=q1un49VCEGqoab5d6eEPmUutNChcVgonPkx0MMaWuvs=; 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=jFCvr1xTUUiB3uG+W0S6+DeJh5UrglWkEH6XaU8FEER4m0UFNTk6GcGZSg652uiF6 DYJQTRlWlrZL9uP2DNwteN0rsdd1zDNd2m4IXM07CWYAr6apGfM/LIs//Ymxdk48qZ TNt/H1XfxZhklVtbYn9mmMP+3tJ2Akost8/2Nsvs= 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 109843858D35 for ; Mon, 23 Aug 2021 09:28:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 109843858D35 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-573-LDQKfmfgN4e5vU90WI9odg-1; Mon, 23 Aug 2021 05:28:52 -0400 X-MC-Unique: LDQKfmfgN4e5vU90WI9odg-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6DB9A2EFE; Mon, 23 Aug 2021 09:28:51 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.194.2]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 743A26A8FA; Mon, 23 Aug 2021 09:28:49 +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> Date: Mon, 23 Aug 2021 11:28:47 +0200 In-Reply-To: <20210822124546.154232-2-hjl.tools@gmail.com> (H. J. Lu's message of "Sun, 22 Aug 2021 05:45:46 -0700") Message-ID: <87fsv0se5s.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.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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: libc-alpha@sourceware.org, Szabolcs Nagy , Joseph Myers , "Kirill A . Shutemov" Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" * H. J. Lu: > By default, the number of the address bits used in address translation > is the number of address bits. But it can be changed by ARM Top-byte > Ignore (TBI) or Intel Linear Address Masking (LAM). I think the fundamental concern is that we don't really know today how this API would be used. Szabolcs has said that Arm doesn't need this API for HWSAN. TBI has already other (incompatible) users, I think. (Although OpenJDK's ZGC garbage collector has moved off it.) My concern is that this interface essentialyl sets in stone a certain programming model for LAM, and we really don't know today if that's the right approach. I also expect that HWSAN needs to poke at glibc internals, like the other sanitizers, so I don't see why calling a kernel API behind glibc's back would be problematic. As a side effect of the libpthread merge, we freed DF_1_INITFIRST for other uses, so you should be able to work around initialization ordering issues, too. Thanks, Florian