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_HI,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 B07221F8C6 for ; Sat, 21 Aug 2021 16:38:52 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E29B2384F029 for ; Sat, 21 Aug 2021 16:38:51 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org E29B2384F029 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1629563931; bh=9qeYMLGydBBRmHzTSnLG/ZkQv2P7H/GCWRdRB3wFP/Y=; 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=hpB5Jyw9jojZnNT/2N5qH3/xPAsuVAxuCctqMFo6zv3nRR1MFDrbvT1vvye+MW1fh 6xdsIg3+rW+koQiAh34fXnBU7IVkQe6rrGXAFX/2jCpOCxQ7wj+creOUA3zzxTlOEB Ir75bFmxNm4RW6fiGHm8KPqe1XBKuzHE8ngjXoAA= Received: from mail-pg1-x52a.google.com (mail-pg1-x52a.google.com [IPv6:2607:f8b0:4864:20::52a]) by sourceware.org (Postfix) with ESMTPS id C79C0385C421 for ; Sat, 21 Aug 2021 16:38:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C79C0385C421 Received: by mail-pg1-x52a.google.com with SMTP id x4so12334411pgh.1 for ; Sat, 21 Aug 2021 09:38:31 -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=9qeYMLGydBBRmHzTSnLG/ZkQv2P7H/GCWRdRB3wFP/Y=; b=MLr6svQ6bv3TCxGDwpytofcOPIEY0BGzYO+wIWD2jfSvzUIrgsXuZBx8CimhlU0YBz Am66ewB7GwScA3bOtp9PA11XWyi6JO48c080lU+oO4oOuhKXn4zfim6VIS4fVJxCpxUr 2GXVNJJ/SazKmTCnM/2JSa5e2dPHjg+fNXxu0ismIJceITvGYMTeyX6nGF1Ia+HMrFGT ZVEIWZcARBs9KWkFifx8nr7JE/dZmDWSOs16IhG2/7KrSqPIC/fvRSj2MwVB80CY2sWs FXinJWIfHzrnuPjKINsr9xY2ISjrENdJIaEuJCeanIzfxJTs6kGQ85zzuK6sXRJtn1dC lF1w== X-Gm-Message-State: AOAM533SQjIj1afpRcmnWKS9cVAaQNt6sVLIAJdNPr9akPbExYmFid1z F2XpJVgEnCKnxuDJwhJrWuk5cIPWkMN2AzUoDeg= X-Google-Smtp-Source: ABdhPJx30/EtfrKv3iEjXsYCxYN4sg22AY/WYPipjlaMArNxv8puHcMotE19noK2QzJ9a5oXhPrZmbwwgNyRK461rkk= X-Received: by 2002:a63:164a:: with SMTP id 10mr24399927pgw.161.1629563910920; Sat, 21 Aug 2021 09:38:30 -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 09:37:55 -0700 Message-ID: Subject: Re: [PATCH v5 1/1] : An API for tagged address To: Sunil Pandey 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: "H.J. Lu via Libc-alpha" Reply-To: "H.J. Lu" 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: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 wrot= e: >> > >> > * 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 Addres= s, 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 translat= ion >> > > +is the number of address bits. But it can be changed by ARM Top-by= te >> > > +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 var= ious ARM >> contrib.texi:his maintainership of the ARM and MIPS architectures and th= e 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 p= orts. >> >> I will keep ARM. >> >> > > +@Theglibc{} provides several functions and macros in the header fil= e >> > > +@file{sys/tagged-address.h} to manipulate tagged address bits, whic= h 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 >> > >> > >> > >> > implies that the tag bits are those that are ignored for address >> > translation purposes (e.g., =E2=80=9CThe syscall behaviour for a valid= 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 untranslated >> > intra-page offset). >> > >> > I find it more intuitive to refer to the ignored bits as =E2=80=9Ctagg= ed 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 m= ore clear to me than the proposed new name(set_translated_address_mask). Fo= r the proposed new name, it is not clear which particular portion of addres= s will be masked. > How about set_address_tagbit_mask? Can you give it an example of how set_address_tagbit_mask should be used? >> >> >> > > +@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{m= ask}. >> > > +Only bits set in @var{mask} will be used in address translation. T= he >> > > +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= =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 crea= tion. >> >> > 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 allocati= on >> > 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. >> >> -- >> H.J. --=20 H.J.