From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102e.google.com (mail-pj1-x102e.google.com [IPv6:2607:f8b0:4864:20::102e]) by sourceware.org (Postfix) with ESMTPS id 5C369385842B for ; Fri, 20 Aug 2021 23:27:06 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5C369385842B Received: by mail-pj1-x102e.google.com with SMTP id u13-20020a17090abb0db0290177e1d9b3f7so14947021pjr.1 for ; Fri, 20 Aug 2021 16:27:06 -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:content-transfer-encoding; bh=AXiWXNxBs46MjChESbCpeLZq1bJz5ps/uNYivy4s+fs=; b=m6sOIoBlzIQKm4BcnSU+Lr/13ld7uU1Dh7JAcMz5SjvOqOhYCVZx7TG9B1rDcQNvjq BqRdl40XgM9HeSVorx6zAVc4iu7n58Hyi2OGRoG1vaWpWc8f+rc5/R2AVutS0HysYLxo vjXjH/mWogFY8Qs5e3VrdflC5vrZ2IzmZ9ehgUEbtwy4kk6jkVhlSZabqo7ZlsDSF6pC RuvOsemiLm7KCYzm/d8ypha5H8S3ZTY9DDG9FwOtEnxn6Ia6D844jcSlDC5F4VnVLXEJ hzg7MnHb4DHiGqB6qHoEPNo35qW4FGkZ8GOV+Krid+lfXkDHDa9tof2RM/ZPbaeF6gfq tfOg== X-Gm-Message-State: AOAM531JkPnNL6086tf2NyfuCoqBHje1Jua+tYs+39f0V5C+dBfObxox smlIs+Q3cvxbmY0jj4de/mjL55WHVJmk9gSr2wM= X-Google-Smtp-Source: ABdhPJzVk9FRey6641gdMv2DCPHXoOftn1boMiEYBDLWfc0/zKfAZp9D9t/pW+VB8ILx0tsE8WBOzcuuiG/ZCEFuOgk= X-Received: by 2002:a17:90a:bc8f:: with SMTP id x15mr6063292pjr.153.1629502025353; Fri, 20 Aug 2021 16:27:05 -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: <87bl63giup.fsf@oldenburg.str.redhat.com> From: "H.J. Lu" Date: Fri, 20 Aug 2021 16:26:29 -0700 Message-ID: Subject: Re: [PATCH v5 1/1] : An API for tagged address To: Florian Weimer Cc: GNU C Library , Joseph Myers , "Kirill A . Shutemov" , Szabolcs Nagy , Adhemerval Zanella , Sunil K Pandey Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3030.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org 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: , X-List-Received-Date: Fri, 20 Aug 2021 23:27:08 -0000 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.texi > > 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 variou= s ARM contrib.texi:his maintainership of the ARM and MIPS architectures and the m= ath 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 port= s. 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 i= s > > +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 > > > > implies that the tag bits are those that are ignored for address > translation purposes (e.g., =E2=80=9CThe syscall behaviour for a valid ta= gged > 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 untranslated > intra-page offset). > > I find it more intuitive to refer to the ignored bits as =E2=80=9Ctagged = address > bits=E2=80=9D. I will rename it to set_translated_address_mask. > > +@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. This > > +function can be called only once before @code{main}. > > Again the restriction around @code{main} is unclear. If it's =E2=80=9Cbe= fore > 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 creatio= n. > I still don't see a way how we can split tag address bits used by the > 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-line > object header (found via a hash table, for example), and utilize the > fact that mmap-based allocations are always page-aligned. This would no > core malloc algorithm changes and should be an obvious improvement. > With more substantial changes, we could use another bit to encode that > an allocation is in a small objects region and does not have an > immediately preceding object header, either. Introducing small object > 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. --=20 H.J.