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=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_REPLYTO_END_DIGIT, HK_RANDOM_REPLYTO,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 [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 C7DA91F8C6 for ; Sat, 21 Aug 2021 21:21:26 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id AA9E9385DC26 for ; Sat, 21 Aug 2021 21:21:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org AA9E9385DC26 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629580885; bh=dStiklu7Xo/6fO8YAiHSogAtnh0ohEdangfVJSSnFUU=; h=References:In-Reply-To:Date:Subject:To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=tgUq8335IEWmanmffVda43WxLMtRWGdzkAyYrzMn5/ALGsaK9VHoOKhc/m8XPvz03 CR/FfOuAFStI9UHEplsHFxIWazwzvbBXOQYiHD7GdmOJYN/aYJRRnLfl0YMdq4ZmTE /iiHVyjcfooUtYAYj9KGkfqghb5U5YK7t3TRzzjI= Received: from mail-qk1-x72b.google.com (mail-qk1-x72b.google.com [IPv6:2607:f8b0:4864:20::72b]) by sourceware.org (Postfix) with ESMTPS id 3FCD03858417 for ; Sat, 21 Aug 2021 21:21:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3FCD03858417 Received: by mail-qk1-x72b.google.com with SMTP id e14so14844276qkg.3 for ; Sat, 21 Aug 2021 14:21:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=18yk3XFme6ie0zFPp+vKyRXUxp3bpngTIwKh9MKfOW0=; b=sqzvLSCqEcDfK+CrkkEtbEZjxjLJC7AsGx1BYNd4yyUG/r3sETTwOVnTbdQQd6Jtqd AfB01m56dPQorg9Kge3brjXkkPb+mSm4HyD3cgM+FO2qYEEat0mxjmE+NaHArYc37Rfm EYdGmWjZOe9ak3QjKhkobzjnZS7GUk1w441RX+FfSdVb/aTMAlwwGzEGwQSGbd+iIKFY y8so5/X4I1AmuniJk7eE2UI+3OwcTcWWWCEBBsl9+TLII+BslolXFkExR1cgOdaHQfVX YPw5tvBQgejM5ptexHENZYj0KgAscBizI6tYX5LEDbMChBV+dPCE1ABVYONHqRqCpKhU gJzA== X-Gm-Message-State: AOAM533S4GlWDLHPSzCqd0Wmgvilj/e7eG3Yb4jTjB+9oJzuJ7oJN4Yp n3dXEf35jibO0mGCYsqfo6NgaINcYGynIKzfnrE= X-Google-Smtp-Source: ABdhPJzKPstXNV2cxiqSwgB2c00wuiK+VjMfRUtPyifUvlza1oMgwyfAH1Ul5/e6lvv78APrQArzFrR9oX4nB0wQefs= X-Received: by 2002:a37:a147:: with SMTP id k68mr14720154qke.416.1629580863908; Sat, 21 Aug 2021 14:21:03 -0700 (PDT) MIME-Version: 1.0 References: <20210805131358.300475-1-hjl.tools@gmail.com> <20210805131358.300475-2-hjl.tools@gmail.com> <87bl63giup.fsf@oldenburg.str.redhat.com> In-Reply-To: Date: Sat, 21 Aug 2021 14:20:28 -0700 Message-ID: Subject: Re: [PATCH v5 1/1] : An API for tagged address To: "H.J. Lu" Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Sunil Pandey via Libc-alpha Reply-To: Sunil Pandey Cc: Florian Weimer , GNU C Library , Szabolcs Nagy , Joseph Myers , "Kirill A . Shutemov" Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" On Sat, Aug 21, 2021 at 9:38 AM H.J. Lu wrote: > On Sat, Aug 21, 2021 at 9:10 AM Sunil Pandey wrote: > > > > > > > > On Fri, Aug 20, 2021 at 4:27 PM H.J. Lu wrote: > >> > >> On Thu, Aug 12, 2021 at 1:36 AM Florian Weimer > wrote: > >> > > >> > * H. J. Lu: > >> > > >> > > diff --git a/manual/ctype.texi b/manual/ctype.texi > >> > > index d0618c5c38..28af73ff0e 100644 > >> > > --- a/manual/ctype.texi > >> > > +++ b/manual/ctype.texi > >> > > @@ -1,4 +1,4 @@ > >> > > -@node Character Handling, String and Array Utilities, Memory, Top > >> > > +@node Character Handling, String and Array Utilities, Tagged > Address, Top > >> > > @c %MENU% Character testing and conversion functions > >> > > @chapter Character Handling > >> > > >> > Allegedly, it should not be necessary to maintain the @node linkage > >> > manually (if we remove it). > >> > >> Since @node isn't removed, I guess I have to keep this change. > >> > >> > > diff --git a/manual/tagged-address.texi b/manual/tagged-address.te= xi > >> > > new file mode 100644 > >> > > index 0000000000..a3929a0eb7 > >> > > --- /dev/null > >> > > +++ b/manual/tagged-address.texi > >> > > @@ -0,0 +1,80 @@ > >> > > +@node Tagged Address, Character Handling, Memory, Top > >> > > +@c %MENU% Tagged address functions and macros > >> > > +@chapter Tagged Address > >> > > + > >> > > +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). > >> > > >> > Current spelling is =E2=80=9CArm=E2=80=9D, I think. > >> > >> There are > >> > >> contrib.texi:Philip Blundell for the ports to Linux/ARM > >> contrib.texi:(@code{arm-@var{ANYTHING}-linuxaout}) and ARM standalone > >> contrib.texi:Richard Earnshaw for continued support and fixes to the > various ARM > >> contrib.texi:his maintainership of the ARM and MIPS architectures and > the math > >> contrib.texi:encryption support for ARM and various fixes. > >> creature.texi:architectures (i686, ARM), this is planned to change and > >> applications > >> > >> and > >> > >> contrib.texi:Ulrich Weigand for various fixes to the PowerPC64 and Arm > ports. > >> > >> I will keep ARM. > >> > >> > > +@Theglibc{} provides several functions and macros in the header > file > >> > > +@file{sys/tagged-address.h} to manipulate tagged address bits, > which is > >> > > +the number of the address bits used in address translation, with > >> > > +restrictions: > >> > > >> > Aren't the tagged address bits *not* used in address translation? > >> > > >> > The Arm documentation > >> > > >> > < > https://www.kernel.org/doc/html/latest/arm64/tagged-address-abi.html> > >> > > >> > implies that the tag bits are those that are ignored for address > >> > translation purposes (e.g., =E2=80=9CThe syscall behaviour for a val= id tagged > >> > pointer is the same as for the corresponding untagged pointer.=E2=80= =9D). > This > >> > manual change uses the reverse terminology: tagged address bits are > >> > those that are used in address translation (including the untranslat= ed > >> > intra-page offset). > >> > > >> > I find it more intuitive to refer to the ignored bits as =E2=80=9Cta= gged > address > >> > bits=E2=80=9D. > >> > >> I will rename it to set_translated_address_mask. > > > > Existing name set_tagged_address_mask may not be intuitive but it looks > more clear to me than the proposed new name(set_translated_address_mask). > For the proposed new name, it is not clear which particular portion of > address will be masked. > > How about set_address_tagbit_mask? > > Can you give it an example of how set_address_tagbit_mask should > be used? > I looked at the code again, for the set_tagged_address_mask, it will set machine to ignore the upper bits depending on parameters, independent of how upper bits will actually be used by the application. You are correct, api name shouldn't have tagged in it. > > >> > >> > >> > > +@deftypefun int set_tagged_address_mask (uintptr_t @var{mask}) > >> > > +@standards{GNU, sys/tagged-address.h} > >> > > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}} > >> > > +Set the mask for address bits used in address translation to > @var{mask}. > >> > > +Only bits set in @var{mask} will be used in address translation. > The > >> > > +return value is @code{0} on success and @code{-1} on failure. Th= is > >> > > +function can be called only once before @code{main}. > >> > > >> > Again the restriction around @code{main} is unclear. If it's =E2=80= =9Cbefore > >> > allocating memory=E2=80=9D or =E2=80=9Cbefore starting threads=E2=80= =9D, than we should say > >> > that. > >> > >> I will change it to > >> > >> This function can be called only once before @code{main} and thread > creation. > >> > >> > I still don't see a way how we can split tag address bits used by th= e > >> > implementation (glibc, sanitizers) and the application. > >> > > >> > For example, glibc could use a tag bit to indicate whether an > allocation > >> > is in a mmap-based allocation. This way, we could use an out-of-lin= e > >> > object header (found via a hash table, for example), and utilize the > >> > fact that mmap-based allocations are always page-aligned. This woul= d > no > >> > core malloc algorithm changes and should be an obvious improvement. > >> > With more substantial changes, we could use another bit to encode th= at > >> > an allocation is in a small objects region and does not have an > >> > immediately preceding object header, either. Introducing small obje= ct > >> > regions is a much larger change, though. > >> > > >> > >> Tag usage should be exclusive to glibc. set_translated_address_mask > >> tells glibc that tag will be used for another purpose. > >> > >> Thanks. > >> > >> -- > >> H.J. > > > > -- > H.J. >