[PATCH v5 1/1] <sys/tagged-address.h>: An API for tagged address

[H.J. Lu]

On Thu, Aug 12, 2021 at 1:36 AM Florian Weimer <fweimer@redhat.com> 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 “Arm”, 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., “The syscall behaviour for a valid tagged
> pointer is the same as for the corresponding untagged pointer.”).  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 “tagged address
> bits”.

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 “before
> allocating memory” or “before starting threads”, 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 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.

-- 
H.J.