From mboxrd@z Thu Jan 1 00:00:00 1970 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 D6026C02181 for ; Fri, 24 Jan 2025 09:28:51 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 0B865280052; Fri, 24 Jan 2025 04:28:51 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0692928004D; Fri, 24 Jan 2025 04:28:51 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E9937280052; Fri, 24 Jan 2025 04:28:50 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id CD52028004D for ; Fri, 24 Jan 2025 04:28:50 -0500 (EST) Received: from smtpin23.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 804B7120FB7 for ; Fri, 24 Jan 2025 09:28:50 +0000 (UTC) X-FDA: 83041820820.23.DDA6946 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf07.hostedemail.com (Postfix) with ESMTP id 4BFCE40003 for ; Fri, 24 Jan 2025 09:28:48 +0000 (UTC) Authentication-Results: imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf07.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1737710928; a=rsa-sha256; cv=none; b=FQzEFqgL3VWa7VtxnpKarovyfk8QwRWvLS/6kJ5a7M434SsrdWLSx0ih2swy46mG3lAuSl cG1oK9RxuSA1+ScWJhns4yqZ2BK4WesSTd8riBdciJIWn5WP1QTlAhlNX4PHidbKe6/Xkz +6ycJMQB4gQi2iDIVAS2CcAJfX7aP6A= ARC-Authentication-Results: i=1; imf07.hostedemail.com; dkim=none; dmarc=pass (policy=none) header.from=arm.com; spf=pass (imf07.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1737710928; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=GFZbd8ePduqwAlkyzgaIJRotbYLxs4fqnrRC6NtUDlo=; b=IcSmlQQ9SExWu+8yeD6b1lj/GBDm84UDT+cJE8gvm1Szu5LUeozHLAFcgXmy1uiUYbOICO uC5mELiq7yhKL9gOm7v+HzZEKyxPhByEHZ4+Z0L2Rcns6HDehb6qoWvJskq92LTqAyANky 21efxzLiFb/+aRpkUPHBELCX2XJQGAA= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id BC80C497; Fri, 24 Jan 2025 01:29:14 -0800 (PST) Received: from [10.57.95.225] (unknown [10.57.95.225]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 716153F694; Fri, 24 Jan 2025 01:28:44 -0800 (PST) Message-ID: <738fc4af-cbee-4d14-a9eb-0932ecc3371f@arm.com> Date: Fri, 24 Jan 2025 09:28:42 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v1 1/2] mm: Clear uffd-wp PTE/PMD state on mremap() Content-Language: en-GB To: Peter Xu Cc: Andrew Morton , Muchun Song , "Liam R. Howlett" , Lorenzo Stoakes , Vlastimil Babka , Jann Horn , Shuah Khan , David Hildenbrand , =?UTF-8?Q?Miko=C5=82aj_Lenczewski?= , Mark Rutland , linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-kselftest@vger.kernel.org, stable@vger.kernel.org References: <20250107144755.1871363-1-ryan.roberts@arm.com> <20250107144755.1871363-2-ryan.roberts@arm.com> <850479be-000a-45a7-9669-491d4200a988@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 4BFCE40003 X-Stat-Signature: jdhzf1qw5jamezd7cwajk1afry9csm5h X-Rspam-User: X-HE-Tag: 1737710928-371173 X-HE-Meta: U2FsdGVkX18zB+SpTmIvbNQCaRL/iO2qASPiAucVfQ8qQXFfbBblJYvBou2JmcyMpJq//+Y1q9qjSNPWXm+Co9mhvUbh5CSE8Zb71YSQE31/oHAWK6rN2aqe1XWxyGj+MTaNrMw6dlUhtyRvrf8XOjv8Ud875CxBaye8z0bC1gli+GliuCs6NUdj4S8S6/oxJld9oehBtATHjQrYchce1e9McIkmI33/+8/iLVHNE5a3jjd/eMN/gZrXRzoWZjg+iboVoY+jP9OKWeIetlPHyCTaT7hwb/yIfL6HJEe3znRfEABVVScajSvxlow0bs58fXL0h4FsCyhaVC81BUKjaDifDVAnysJ+/u7Zjez1D5YmWyTpDzawxzJKewTZp8IoVZH+hpwQYtMi8sY7p4ipINKHuhXoK20lU/fhdZ2Oxxbg0J6qPmAQxlwp5UFGAvL0IrXaOdx2uTSyT9OhVpJ5Y5hL0y8BT26aeSVE3fvV7fqBfbTxsH9uEnaVt9kpSrNY9aFfPuleGARgf3ianD0dKDd0y+ATjtpSJCqHVLpLah11+toU80behC/KWzYZxDF9Ax2SaefoJYppVNjdUGYgUIXrWuDQNdjMX9tIe4Zl/zhVNv8woKudkU83M9WU7Zqjx0WfuFQiUjSLenU0IRkUjcvdUIwG7yYLMLw854RB3NMop5wnhQoK8ttPtosO+VqM2V1lRtJddvRjRSkxQBrj6DBYfwPy0M8ssY7Agx6DsEzws0NjwDWL+mu1bwf+2nJ62o6IDIRj8CHhoetVj5itL6vFyN6W5ZRkPYUiKw9RYaH56IQQOCmof7tUbM0+cnh9bwVpltqNoR1HPFE4ycg9kXhhsL3qQ8rlautl2BGfNFU1E/4uoZy6RsP15WEZbJowOY+3bKf7Y5lr5lCKuwXPO3fdE+W/uzun8Jd8OuPcTwmU90HnI3GeM6XgxJmrRUNnG/cu0YsN1jVi2npV/hj aOZvQ9JR xQjAABeyPF9BpW8EvWfMQjdcG8W0AwlFWIG9On0TREKPH45EhMqNE4vBOmHwnXIGwdeCEzBS+9O5oTumdAF4MrdTGPVHFnhwdqm3456wgopBqTBVQZmYtkQ/v562r7KDA+EBm3NO4aY3E7WpbpxA6Gjc11Q== 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: On 23/01/2025 17:40, Peter Xu wrote: > On Thu, Jan 23, 2025 at 02:38:46PM +0000, Ryan Roberts wrote: >>> @@ -5470,7 +5471,18 @@ static void move_huge_pte(struct vm_area_struct *vma, unsigned long old_addr, >>> spin_lock_nested(src_ptl, SINGLE_DEPTH_NESTING); >>> >>> pte = huge_ptep_get_and_clear(mm, old_addr, src_pte); >>> - set_huge_pte_at(mm, new_addr, dst_pte, pte, sz); >>> + >>> + if (need_clear_uffd_wp && pte_marker_uffd_wp(pte)) >>> + huge_pte_clear(mm, new_addr, dst_pte, sz); >> >> This is checking if the source huge_pte is a uffd-wp marker and clearing the >> destination if so. The destination could have previously held arbitrary valid >> mappings, I guess? > > I think it should be all cleared. I didn't check all mremap paths, but for > MREMAP_FIXED at least there should be: > > if (flags & MREMAP_FIXED) { > /* > * In mremap_to(). > * VMA is moved to dst address, and munmap dst first. > * do_munmap will check if dst is sealed. > */ > ret = do_munmap(mm, new_addr, new_len, uf_unmap_early); > if (ret) > goto out; > } > > It also doesn't sound right to leave anything in dest range, Yes, of course. And the loop over the old ptes actually skips doing anything if the old pte is none without doing any operations on the new pte; so it must be none by default. OK panic over! I just need to fix the arm64 issue I raised in the other email. I'm going to send a bunch of fixes/improvements in that area. Thanks, Ryan > e.g. if there > can be any leftover dest ptes in move_page_tables(), then it means > HPAGE_P[MU]D won't work, as they install huge entries directly. For that I > do see a hint in the comment too in that path: > > move_normal_pud(): > /* > * The destination pud shouldn't be established, free_pgtables() > * should have released it. > */ > if (WARN_ON_ONCE(!pud_none(*new_pud))) > return false; > > PMD path has similar implications. > > Thanks, >