From patchwork Tue Nov 5 15:50:42 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Harshvardhan Jha X-Patchwork-Id: 13863138 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id C7792D2C13E for ; Tue, 5 Nov 2024 15:50:52 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B9BA06B0098; Tue, 5 Nov 2024 10:50:50 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B245D6B0099; Tue, 5 Nov 2024 10:50:50 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 99EBE6B009A; Tue, 5 Nov 2024 10:50:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 744A96B0098 for ; Tue, 5 Nov 2024 10:50:50 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay05.hostedemail.com (Postfix) with ESMTP id 21CD441473 for ; Tue, 5 Nov 2024 15:50:50 +0000 (UTC) X-FDA: 82752477780.03.9A8CEEF Received: from mx0b-00069f02.pphosted.com (mx0b-00069f02.pphosted.com [205.220.177.32]) by imf24.hostedemail.com (Postfix) with ESMTP id 784BD18000A for ; Tue, 5 Nov 2024 15:50:43 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b="MXmEB/Hb"; spf=pass (imf24.hostedemail.com: domain of harshvardhan.j.jha@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=harshvardhan.j.jha@oracle.com; dmarc=pass (policy=reject) header.from=oracle.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730821763; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=+P0MvUmtvX+pdbAUezamlBg8piG53Ca6UVptHTajYJ8=; b=0CguaAhCtenZH/qrVRJAFV2kXEhDpOqlTx4UvCqpPLnqS49sVsh57tmQIYCPvlZvagENsC lwQBx+fGXbrkdJhBJ73b5O7OiTJnJFXQoIvCQqIv7LcUh1gELKnPjk4RKin68ZW3pi2CJU Zlw9Y21Sf5NEqz0VRTibDLVU4zO56Ds= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730821763; a=rsa-sha256; cv=none; b=Gy2G9eiHc4HnZQSQnrfKH1lF9GQMaj9vMQoH4iJqzF1iv+aUq9ls/ptltuefOVFM+WrRJo tsG5GSlHbQ6UESXA5q7Nwx1dvc92ocL3piZHYHFUs71wp31siZigbwx76ll7XBEhhxsc3V 3bIR1q53BcPtIOD21rJOpn9cLq9+nRM= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=oracle.com header.s=corp-2023-11-20 header.b="MXmEB/Hb"; spf=pass (imf24.hostedemail.com: domain of harshvardhan.j.jha@oracle.com designates 205.220.177.32 as permitted sender) smtp.mailfrom=harshvardhan.j.jha@oracle.com; dmarc=pass (policy=reject) header.from=oracle.com Received: from pps.filterd (m0333520.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.18.1.2/8.18.1.2) with ESMTP id 4A5DiYQV029653; Tue, 5 Nov 2024 15:50:47 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=cc :content-transfer-encoding:date:from:in-reply-to:message-id :mime-version:references:subject:to; s=corp-2023-11-20; bh=+P0Mv UmtvX+pdbAUezamlBg8piG53Ca6UVptHTajYJ8=; b=MXmEB/HbVWDlr4wdK74Kj 2QQX78MaLYq9xOWmsvGB/vC7LZavYWWx6P6wvAKAx7vkCf3Tnlc53CXsI4zq058l CYwL9CrHRUTm+1dPeLxWv6XxsKfw89Lx5F7xjbhl3NtuOpekpkcibxMLo4uOuQpc vJfw8ESYBDOGtN+VW0xMNpMz6hrstaNjniE7JVRnL69fq1LtkCBfh4S6konq3JZ1 vtpcNLKVgfJs5rE7yI96TQMwUHenq4ACAmIJZCfl2mmv1KxX6ChUieo/FK4gJ8y/ Eiv7jIHSof7qqd7a6lll1plPMLnVMPTZUaxHiOksg13BnSJ40sdJqB09KsySU0OC Q== Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.appoci.oracle.com [147.154.18.20]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 42nc4bwqs5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 05 Nov 2024 15:50:46 +0000 (GMT) Received: from pps.filterd (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (8.18.1.2/8.18.1.2) with ESMTP id 4A5EUi9w035597; Tue, 5 Nov 2024 15:50:46 GMT Received: from pps.reinject (localhost [127.0.0.1]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 42nahdkgkv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 05 Nov 2024 15:50:46 +0000 Received: from iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by pps.reinject (8.17.1.5/8.17.1.5) with ESMTP id 4A5Foi0M028682; Tue, 5 Nov 2024 15:50:45 GMT Received: from ca-dev112.us.oracle.com (ca-dev112.us.oracle.com [10.129.136.47]) by iadpaimrmta02.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTP id 42nahdkghq-3; Tue, 05 Nov 2024 15:50:45 +0000 From: Harshvardhan Jha To: akpm@linux-foundation.org Cc: harshvardhan.j.jha@oracle.com, linux-mm@kvack.org, stable@vger.kernel.org Subject: [PATCH 5.10.y 2/2] mm: avoid leaving partial pfn mappings around in error case Date: Tue, 5 Nov 2024 07:50:42 -0800 Message-ID: <20241105155042.288813-3-harshvardhan.j.jha@oracle.com> X-Mailer: git-send-email 2.46.0 In-Reply-To: <20241105155042.288813-1-harshvardhan.j.jha@oracle.com> References: <20241105155042.288813-1-harshvardhan.j.jha@oracle.com> MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.293,Aquarius:18.0.1057,Hydra:6.0.680,FMLib:17.12.62.30 definitions=2024-11-05_06,2024-11-05_01,2024-09-30_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 spamscore=0 mlxlogscore=971 mlxscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2409260000 definitions=main-2411050122 X-Proofpoint-ORIG-GUID: y1O3ccfMcuZIrW3QjvrQnmENMAZREd1X X-Proofpoint-GUID: y1O3ccfMcuZIrW3QjvrQnmENMAZREd1X X-Rspamd-Server: rspam10 X-Stat-Signature: 1nuznmudfa8a5m55hdf7uocf8m3c1hod X-Rspamd-Queue-Id: 784BD18000A X-Rspam-User: X-HE-Tag: 1730821843-183838 X-HE-Meta: U2FsdGVkX1+ukphRhc/+c5IRU+rEEriVmPUojFf3zwfummdqo0b6Ov+vYJdj1hwHt3Yv5MHvuJJIVZNYxanUm0LAd6zYvHWfziHj2am0zVhkk8fzGTpllN7JMYNpt+w1vpj2Jr7yymYBvxrojQb17GSWJxN2YZpdl6VmLQGj0nMcOdl8gthz9nvZ3SIp5pbXPF8RbrU0LbAqRz10wD6cCqCC4oB7mS1mdWsKoESCtRjdepRweZRjoQxWuhcCItx9rkzCjQxh9SEEMwhm6wjCMIXKnM+P/Xy1iNsC+7XzELbzfL80NG/hs7vvpXO+Lb0VIP+cU72jI2L/7EoDlUg0FsArxuiyEhv0fN/gSOODsD9Xj/XgBC1u5WmCDs7UYzE2H7Fa4clGNd31W/Exjq9OroHGJAFrD/KmzBLIKbb7nYKytqnE13nZYkLvYR22HT28rwX3ML/+jY6dC4cebaw4phOq+kYftVyzvuqPzMzr/HcQBWPaEVMdUnu4fc26ydHAJYPq/EJiRCd2CIxh2aQMBUJdBp+kR0Iyw2CpiLmbdfusTrOEu0NuNq82Q7W1ma4xq51cMT9tQJSjaro3f0o5dh11z47uC59fSUxGmJUUsQdWspin/bu2eEWxEP+NnqlRTs0zpe+XChJkjwA9g6sI8VZKnpmg0+VgIcyuV5soZ2X6JB2dD/LuowCYwyuyJgOG1s8PDSshm0ZBlZHVsFk9ZD3G0IXWtZwYuDcYSj10913dtprIZFJXHplD248yrYErMgKD+8uXugxExpA5JpTMxuh7M2K4kpIHEhMzVQExRTJFK4ujweIMCooAxtxcNbucxSmF/8xsE465sYSt7ZoYyaQoLiG27BigIUDcWDoFzOCVdEwnB1Kh8F/kbx82ZtfNaF+Nsamz+id9zgsCDNmaCSPC84IQWNc1ryvph39IdqHCtBfZLLeasOgvnL4WvAdYWic9SUKy4VyuuABDhpQ oC1efjjc /YMzoGqg6DrY4x0yWe4P4kcrqPpPDwv4BPw8LUoJXAyTY/ZSZ1Vh+bOJ43uAlzm/n8ZKw0ufb8cAewuZ/OW2szA42PmWaKXjZhhfIujjRtl/OttDuhL3YWgFirIqNsikWerIkEOcwlYiabwPF4nAHr8eXprj1B9xC3xnKDqRNPX6f+UWcy4dMkJOz9SRrhsoP8mJRYez8ZoLYrkh4u6FJq0dQ3emBb6qbNmR5GFxetGs9mImBbz7k6HA3sMeQd83nqvrin1oqa87Ixt6fqmHI5djEgZ5SY1PUZVIRgHxBXY6xeyk5qtvYvl3ka7BghdvtlrSFQ6G3ICEGEdGIAAd1JrXpSSs322m9r/3gA3qesF4Es5t3v7Dj0kiRkJBKl6AptUQzPGV6weP7qa0xDVXng/2Ior0ChOV9Yom1LWCdrVQRwYDtv+Gia5aIC2lH0pFndxWwxwrn9aM+T4BeL9nRnl8kn1p/5oKwrdnNlzknquarAz/h7yNppSKtL08IOHi4gLPKmi3crOPWKc6oeaFRKN2I/A== X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: From: Linus Torvalds commit 79a61cc3fc0466ad2b7b89618a6157785f0293b3 upstream. As Jann points out, PFN mappings are special, because unlike normal memory mappings, there is no lifetime information associated with the mapping - it is just a raw mapping of PFNs with no reference counting of a 'struct page'. That's all very much intentional, but it does mean that it's easy to mess up the cleanup in case of errors. Yes, a failed mmap() will always eventually clean up any partial mappings, but without any explicit lifetime in the page table mapping itself, it's very easy to do the error handling in the wrong order. In particular, it's easy to mistakenly free the physical backing store before the page tables are actually cleaned up and (temporarily) have stale dangling PTE entries. To make this situation less error-prone, just make sure that any partial pfn mapping is torn down early, before any other error handling. Reported-and-tested-by: Jann Horn Cc: Andrew Morton Cc: Jason Gunthorpe Cc: Simona Vetter Signed-off-by: Linus Torvalds Signed-off-by: Greg Kroah-Hartman (cherry picked from commit 5b2c8b34f6d76bfbd1dd4936eb8a0fbfb9af3959) Signed-off-by: Harshvardhan Jha --- mm/memory.c | 27 ++++++++++++++++++++++----- 1 file changed, 22 insertions(+), 5 deletions(-) diff --git a/mm/memory.c b/mm/memory.c index 40a6cc6df9003..29cce8aadb618 100644 --- a/mm/memory.c +++ b/mm/memory.c @@ -2290,11 +2290,7 @@ static inline int remap_p4d_range(struct mm_struct *mm, pgd_t *pgd, return 0; } -/* - * Variant of remap_pfn_range that does not call track_pfn_remap. The caller - * must have pre-validated the caching bits of the pgprot_t. - */ -int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long addr, +static int remap_pfn_range_internal(struct vm_area_struct *vma, unsigned long addr, unsigned long pfn, unsigned long size, pgprot_t prot) { pgd_t *pgd; @@ -2347,6 +2343,27 @@ int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long addr, return 0; } +/* + * Variant of remap_pfn_range that does not call track_pfn_remap. The caller + * must have pre-validated the caching bits of the pgprot_t. + */ +int remap_pfn_range_notrack(struct vm_area_struct *vma, unsigned long addr, + unsigned long pfn, unsigned long size, pgprot_t prot) +{ + int error = remap_pfn_range_internal(vma, addr, pfn, size, prot); + + if (!error) + return 0; + + /* + * A partial pfn range mapping is dangerous: it does not + * maintain page reference counts, and callers may free + * pages due to the error. So zap it early. + */ + zap_page_range_single(vma, addr, size, NULL); + return error; +} + /** * remap_pfn_range - remap kernel memory to userspace * @vma: user vma to map to