unofficial mirror of libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: "H.J. Lu via Libc-alpha" <libc-alpha@sourceware.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: Szabolcs Nagy <szabolcs.nagy@arm.com>,
	libc-alpha@sourceware.org,
	"Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
	Joseph Myers <joseph@codesourcery.com>,
	Vedvyas Shanbhogue <vedvyas.shanbhogue@intel.com>
Subject: Re: [PATCH v4 1/2] <sys/tagged-address.h>: An API for tagged address
Date: Wed, 21 Apr 2021 16:21:06 -0700	[thread overview]
Message-ID: <CAMe9rOrsqKFj9pWb4fP+gVSoS9+J8P0gnPfLJdUfwk2zUoNm0A@mail.gmail.com> (raw)
In-Reply-To: <8735vkqh38.fsf@oldenburg.str.redhat.com>

[-- Attachment #1: Type: text/plain, Size: 6024 bytes --]

On Tue, Apr 20, 2021 at 11:36 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * H. J. Lu:
>
> > diff --git a/manual/tagged-address.texi b/manual/tagged-address.texi
> > new file mode 100644
> > index 0000000000..ce10f7e752
> > --- /dev/null
> > +++ b/manual/tagged-address.texi
> > @@ -0,0 +1,59 @@
> > +@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).
> > +
> > +@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.
> > +@pindex sys/tagged-address.h
>
> I don't under stand the “which is the number of address bits” part.

For tagged addresses, not all bits are used in address translation.
For TBI, only the lower 48 bits are used in address translation.
For LAM, it can be either the lower 48 bits or 57 bits.

> This section needs to describe under which circumstances it is valid to
> alter the tag bits in pointers returned from glibc functions (including

Tagged address is enabled only when get_tagged_address_mask () != -1.

> system call wrappers).  I think at least historically, the kernel
> required masking tag bits in user space for TBI.

I believe this has been fixed in the recent kernel.

> > +@deftypefun {unsigned int} get_tagged_address_bits (void)
> > +@standards{GNU, sys/tagged-address.h}
> > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> > +Get the current address bits used in address translation.  The return
> > +value is @code{0} if tag bits are not the highest bits in address.
> > +@end deftypefun
>
> “in addresses”?

Fixed.

> What is the return value if there are no tag bits available?  The word
> width?

I am adding:

The return value is the number of address bits when tagged address is
unsupported.

>
> > +@deftypefun uintptr_t get_tagged_address_mask (void)
> > +@standards{GNU, sys/tagged-address.h}
> > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> > +Get the current mask for address bits used in address translation.
> > +@end deftypefun
>
> Mask is ambiguous in this context.  If a bit is set in the return value,
> will this bit take part in address translation or not?  Please be
> explicit here.

Fixed.

> > +@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}.
> > +The return value is @code{0} on success and @code{-1} on failure.  This
> > +function can be called only once before @code{main}.  The possible
> > +@code{errno} error conditions are @code{ENODEV}, @code{EPERM},
> > +@code{EINVAL}, and @code{ENOSYS}.
> > +@end deftypefun
>
> Likewise, please clarify if bits set in MASK participate in address
> translation or not.

Fixed.

> Why before main?  Do you mean it can only be called once per process?

The feedback is that it should be called as early as possible:

https://sourceware.org/pipermail/libc-alpha/2021-February/122795.html

> I think this limitation suggests we should use ELF markup for this.
> There are definitely compatibility issues to work out here.

See:

https://gitlab.com/x86-psABIs/x86-64-ABI/-/commits/usr/hjl/lam

> Historically, the x86-64 psABI supplement implied that the top 16 bits
> are available for application use (without hardware masking obviously).
> If e.g. malloc starts returning tagged addresses, that assumption
> breaks.

These applications must be changed to support LAM.

> Should glibc allocate tag bits to different libraries within the same
> process?  For example, so that malloc could get 2 tag bits, the main
> program 3 and some other library 1 bit?

My API proposal doesn't prevent this scheme.

> For glibc malloc, it would be a simple enhancement to move the
> IS_MMAPPED to a tag bit, and eliminate the malloc header for mmap'ed
> chunks, replacing it with a separate data structure.  This would allow
> us to preserve page alignment for mmap'ed chunks without wasting an
> entire page for each allocation, just to store the malloc header.
>
> > +@deftypefun {void *} tag_address (void *@var{addr}, unsigned int @var{tag})
> > +@standards{GNU, sys/tagged-address.h}
> > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> > +Return the address of @var{addr} with the tag value @var{tag} stored
> > +in the untranslated bits.  Overflow of @var{tag} in the untranslated
> > +bits are ignored.
> > +@end deftypefun
> > +
> > +@deftypefun {void *} untag_address (void *@var{addr})
> > +@standards{GNU, sys/tagged-address.h}
> > +@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
> > +Return the address of @var{addr} with all zero untranslated bits.
> > +@end deftypefun
>
> This should reference the earlier discussion about when it is safe to
> tag and untag addresses.
>
> > +@deftypefn Macro int TAGGED_ADDRESS_VALID_BITS (@var{bits})
> > +This macro returns a nonzero value (true) if @var{bits} a valid tagged
> > +address bits.
> > +@end deftypefn
>
> “are valid tagged”?
>
> Does “valid” mean in this context that “the CPU can be configured to
> ignore bits set in BITS during address translation using
> set_tagged_address_mask”?
>
> > +@deftypefn Macro {const uintptr_t} TAGGED_ADDRESS_MASK (@var{bits})
> > +This macro returns a nonzero value if it can be used as mask for constant
> > +address @var{bits} used in address translation.
> > +@end deftypefn
>
> I do not understand the description.

Fixed.

I am enclosing the updated tagged-address.texi here.

Thanks.

-- 
H.J.

[-- Attachment #2: tagged-address.texi --]
[-- Type: text/x-texinfo, Size: 2866 bytes --]

@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).

@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.
@pindex sys/tagged-address.h

@deftypefun {unsigned int} get_tagged_address_bits (void)
@standards{GNU, sys/tagged-address.h}
@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
Get the current address bits used in address translation.  The return
value is @code{0} if tag bits are not the highest bits in addresses.  The
return value is the number of address bits when tagged address is
unsupported.
@end deftypefun

@deftypefun uintptr_t get_tagged_address_mask (void)
@standards{GNU, sys/tagged-address.h}
@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
Get the current mask for address bits used in address translation.  If a
bit is set in the return value, this bit is used in address translation.
The return value is @code{-1} when all bits are used in address
translation.
@end deftypefun

@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}.  The possible
@code{errno} error conditions are @code{ENODEV}, @code{EPERM},
@code{EINVAL}, and @code{ENOSYS}.
@end deftypefun

@deftypefun {void *} tag_address (void *@var{addr}, unsigned int @var{tag})
@standards{GNU, sys/tagged-address.h}
@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
Return the address of @var{addr} with the tag value @var{tag} stored
in the untranslated bits.  Overflow of @var{tag} in the untranslated
bits are ignored.
@end deftypefun

@deftypefun {void *} untag_address (void *@var{addr})
@standards{GNU, sys/tagged-address.h}
@safety{@prelim{}@mtsafe{}@assafe{}@acsafe{}}
Return the address of @var{addr} with all zero untranslated bits.
@end deftypefun

@deftypefn Macro int TAGGED_ADDRESS_VALID_BITS (@var{bits})
This macro returns a nonzero value (true) if @var{bits} is a valid
constant number of the lower address bits which can be used in address
translation.
@end deftypefn

@deftypefn Macro {const uintptr_t} TAGGED_ADDRESS_MASK (@var{bits})
This macro returns a nonzero value which can be passed to
@code{set_tagged_address_mask} to specify the lower address @var{bits}
for address translation.
@end deftypefn

  reply	other threads:[~2021-04-21 23:21 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20  2:18 RFC [PATCH v4 0/2] <sys/tagged-address.h>: An API for tagged address H.J. Lu via Libc-alpha
2021-04-20  2:18 ` [PATCH v4 1/2] " H.J. Lu via Libc-alpha
2021-04-21  6:36   ` Florian Weimer via Libc-alpha
2021-04-21 23:21     ` H.J. Lu via Libc-alpha [this message]
2021-04-22  9:43       ` Szabolcs Nagy via Libc-alpha
2021-04-20  2:18 ` [PATCH v4 2/2] <sys/tagged-address.h>: Update libc.abilist files H.J. Lu via Libc-alpha

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/libc/involved.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMe9rOrsqKFj9pWb4fP+gVSoS9+J8P0gnPfLJdUfwk2zUoNm0A@mail.gmail.com \
    --to=libc-alpha@sourceware.org \
    --cc=fweimer@redhat.com \
    --cc=hjl.tools@gmail.com \
    --cc=joseph@codesourcery.com \
    --cc=kirill.shutemov@linux.intel.com \
    --cc=szabolcs.nagy@arm.com \
    --cc=vedvyas.shanbhogue@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).