On Mon, 8 Feb 2021 at 14:10, Peter Maydell <[email protected]> wrote: > > On Wed, 3 Feb 2021 at 19:00, Richard Henderson > <[email protected]> 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 <[email protected]> > > --- > > 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 <[email protected]> thanks -- PMM
