Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp33379ybj; Fri, 8 May 2020 06:00:13 -0700 (PDT) X-Google-Smtp-Source: APiQypK1lM+kiOu3/jxgg1qskgbqKx6QWuV3oJHIMT8KgEJDAVRBTBp7ZfVc9ueaVBpi5rLXmXky X-Received: by 2002:a50:88a1:: with SMTP id d30mr2004020edd.88.1588942812974; Fri, 08 May 2020 06:00:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588942812; cv=none; d=google.com; s=arc-20160816; b=rSwUbUGXC3pjTIpme8UdgukoAQEu3XcJSbBm1ntJv0d/xPa7ODKLYKCjqvoHNKwQ+Y 7ABHgTNGdtw6VGwPnOKxfaoMUFp87Qk6FB6pDxhv+DxsA26YaaEc+ICmJxNkWx0R/0bp oSqYdo6tNMQNeGYRsWKr/sYmxQTrw16L3rWaGNY1IZ9PiZ2749Hl6f8lkSKd7v+tiT9U db4Nw4nBcKgf4Uvy6hXM3E3sGlzcIQfRsQE8BhvjqyrUP1A6XoBO+RIkdntyb9n8xEHa MTHpEjYA3ieBaqfg/vzKGI/kJRsf1+oZXclAYdZBvAPgotbkpP/VfE57CZgnn9KBgV6F D3tQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:message-id:date:subject:cc:to :from:dkim-signature; bh=Rb7iTD1aSGnWICICNaXcZ/zPpt+9YVVl62vf0KtntEk=; b=q/QVRolZ0kDSPtBQNsNx5rqdFSVV/Ts+5boPW3qAmwNN8NDXkGYJAXuXAt9ESSoMFI D3kNDjfrKZP/CM4JJ8uqNFMMrlBgM3/w2I1pW2SAaLA/R5LfiE8BuvW+54gxcfHWYifs Yl2ciSDj+Yc4OK77nUr974VUb5mMeJoQU7quFvjBB/4eSv8GtMoqN4xxLA4JwTt14Zfn /NNIZ0ihpWobtrpP+3WrzZDqgxlatiwZPPIQrv4yi/QF64MKk0y7LAaPkqrq8r0lojjT 2vHU7X87S3Xcm6KQXUOceDkygHFq/KtNgFD2lTZvIWsy78JRHjittHQ4ifDqLp+8DVhs +qeQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=sZ6ZNUBl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id c2si881477edm.499.2020.05.08.05.59.49; Fri, 08 May 2020 06:00:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=sZ6ZNUBl; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730429AbgEHM4T (ORCPT + 99 others); Fri, 8 May 2020 08:56:19 -0400 Received: from mail.kernel.org ([198.145.29.99]:39710 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729934AbgEHM4S (ORCPT ); Fri, 8 May 2020 08:56:18 -0400 Received: from localhost (83-86-89-107.cable.dynamic.v4.ziggo.nl [83.86.89.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id CE32224969; Fri, 8 May 2020 12:56:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1588942577; bh=f0xr2TAEkyL4kye8GmlZwNW+yvmgzpgCK7AqH3ydBQA=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=sZ6ZNUBlW6T58Dg1C/oXzpBwUS162kInjlfB4KNAaTEVB8JsDPLdHC5McdWmyRw/H +ea90G8hxyPxVDfoCiv56nWKDLxsMEgd2jYcB+TkCS9yeNUSdQfHVl9NQ9ECBRVlTn XHfDm30INKPWEjG96GPjILXzhdef6FD+FeGEVGoY= From: Greg Kroah-Hartman To: linux-kernel@vger.kernel.org Cc: Greg Kroah-Hartman , stable@vger.kernel.org, Linus Torvalds , Catalin Marinas , Will Deacon Subject: [PATCH 5.6 49/49] mm/mremap: Add comment explaining the untagging behaviour of mremap() Date: Fri, 8 May 2020 14:36:06 +0200 Message-Id: <20200508123049.580997355@linuxfoundation.org> X-Mailer: git-send-email 2.26.2 In-Reply-To: <20200508123042.775047422@linuxfoundation.org> References: <20200508123042.775047422@linuxfoundation.org> User-Agent: quilt/0.66 MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Will Deacon commit b2a84de2a2deb76a6a51609845341f508c518c03 upstream. Commit dcde237319e6 ("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 Acked-by: Linus Torvalds Reviewed-by: Catalin Marinas Signed-off-by: Will Deacon Signed-off-by: Catalin Marinas Signed-off-by: Greg Kroah-Hartman --- mm/mremap.c | 10 ++++++++++ 1 file changed, 10 insertions(+) --- a/mm/mremap.c +++ b/mm/mremap.c @@ -606,6 +606,16 @@ SYSCALL_DEFINE5(mremap, unsigned long, a 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))