Re: [PATCH v5 13/31] linux-user: Explicitly untag memory management syscalls

[Peter Maydell]

On Wed, 3 Feb 2021 at 19:00, Richard Henderson
<richard.henderson@linaro.org> wrote:
>
> We define target_mmap et al as untagged, so that they can be
> used from the binary loaders.  Explicitly call cpu_untagged_addr
> for munmap, mprotect, mremap syscall entry points.
>
> Add a few comments for the syscalls that are exempted by the
> kernel's tagged-address-abi.rst.
>
> Signed-off-by: Richard Henderson <richard.henderson@linaro.org>
> ---
>  linux-user/syscall.c | 11 +++++++++++
>  1 file changed, 11 insertions(+)
>
> diff --git a/linux-user/syscall.c b/linux-user/syscall.c
> index 748893904e..4451f8e4f0 100644
> --- a/linux-user/syscall.c
> +++ b/linux-user/syscall.c
> @@ -889,6 +889,8 @@ abi_long do_brk(abi_ulong new_brk)
>      abi_long mapped_addr;
>      abi_ulong new_alloc_size;
>
> +    /* brk pointers are always untagged */
> +
>      DEBUGF_BRK("do_brk(" TARGET_ABI_FMT_lx ") -> ", new_brk);
>
>      if (!new_brk) {

It's not clear to me from
https://www.kernel.org/doc/Documentation/arm64/tagged-address-abi.rst
whether brk() pointers are "always untagged", or only "always untagged
when at stage 1 of relaxation"... Unlike shmat and shmdt pointers,
they aren't listed in the section 3 "must be untagged regardless
of the ABI relaxation" part of the doc. I've asked the kernel folks
for clarification.

Same applies to mmap() and mremap() new_address.

thanks
-- PMM