mm/mremap: Add comment explaining the untagging behaviour of mremap()
BugLink: https://bugs.launchpad.net/bugs/1878040 commitb2a84de2a2
upstream. Commitdcde237319
("mm: Avoid creating virtual address aliases in brk()/mmap()/mremap()") changed mremap() so that only the 'old' address is untagged, leaving the 'new' address in the form it was passed from userspace. This prevents the unexpected creation of aliasing virtual mappings in userspace, but looks a bit odd when you read the code. Add a comment justifying the untagging behaviour in mremap(). Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Acked-by: Linus Torvalds <torvalds@linux-foundation.org> Reviewed-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Will Deacon <will@kernel.org> Signed-off-by: Catalin Marinas <catalin.marinas@arm.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> Signed-off-by: Kamal Mostafa <kamal@canonical.com> Signed-off-by: Stefan Bader <stefan.bader@canonical.com>
This commit is contained in:
parent
4208e71800
commit
c0c7e1582e
10
mm/mremap.c
10
mm/mremap.c
|
@ -606,6 +606,16 @@ SYSCALL_DEFINE5(mremap, unsigned long, addr, unsigned long, old_len,
|
|||
LIST_HEAD(uf_unmap_early);
|
||||
LIST_HEAD(uf_unmap);
|
||||
|
||||
/*
|
||||
* There is a deliberate asymmetry here: we strip the pointer tag
|
||||
* from the old address but leave the new address alone. This is
|
||||
* for consistency with mmap(), where we prevent the creation of
|
||||
* aliasing mappings in userspace by leaving the tag bits of the
|
||||
* mapping address intact. A non-zero tag will cause the subsequent
|
||||
* range checks to reject the address as invalid.
|
||||
*
|
||||
* See Documentation/arm64/tagged-address-abi.rst for more information.
|
||||
*/
|
||||
addr = untagged_addr(addr);
|
||||
|
||||
if (flags & ~(MREMAP_FIXED | MREMAP_MAYMOVE))
|
||||
|
|
Loading…
Reference in New Issue