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

[Peter Maydell]

On Mon, 8 Feb 2021 at 14:10, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> 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.

I got back the clarification: these should have been added to
the section 3 "always untagged" list (and they'll update the
kernel docs). So this patch is correct.

Reviewed-by: Peter Maydell <peter.maydell@linaro.org>

thanks
-- PMM