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 DC8EBE6F083 for ; Fri, 1 Nov 2024 19:07:22 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5FD426B0096; Fri, 1 Nov 2024 15:07:22 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 5AC2B6B0098; Fri, 1 Nov 2024 15:07:22 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 49A736B0099; Fri, 1 Nov 2024 15:07:22 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 2DC296B0096 for ; Fri, 1 Nov 2024 15:07:22 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 9AAC1A0DA7 for ; Fri, 1 Nov 2024 19:07:21 +0000 (UTC) X-FDA: 82738458894.18.8393BE5 Received: from nyc.source.kernel.org (nyc.source.kernel.org [147.75.193.91]) by imf02.hostedemail.com (Postfix) with ESMTP id D74D480015 for ; Fri, 1 Nov 2024 19:06:25 +0000 (UTC) Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=LqEo4Jan; spf=pass (imf02.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730487878; 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:dkim-signature; bh=IKp/2fjJK/VTidSurpZeJigkWjv/kb+cKgE/b8FoMAg=; b=H7ilrp0biK1gk9YFJ5SS0+raOnKOsx0mb7p1YvLi71ZOlJrU4dIUYXS35U32YyW0wj66of 5nSL8Y3X63atZDcD8IvPQ9nrCGM8LnsTQeNfhZ2co2v3/0dFV0vH2r9cBVJQwub0rWxmd9 W/uc8+prM/gj2OC37rsEwOEbATlFdoc= ARC-Authentication-Results: i=1; imf02.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=LqEo4Jan; spf=pass (imf02.hostedemail.com: domain of akpm@linux-foundation.org designates 147.75.193.91 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730487878; a=rsa-sha256; cv=none; b=dmanFuphSfAOEBNTAL7/GeTL3pkw4VXU3shlcEkATwwW1s3LsEyf/6f9k45Pi599SOOHyr DUeILn+AkOPYmIAj4HF4v5+7PlP3Amn3fA4FDhOa4SDRqdy4HtO2jawFwFiNJIzUnp/vKj QX5R5deFucC6U0+KZherx5hPMZGDtbk= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by nyc.source.kernel.org (Postfix) with ESMTP id B4765A44B6D; Fri, 1 Nov 2024 19:05:23 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 7B43AC4CECD; Fri, 1 Nov 2024 19:07:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1730488038; bh=L0r/aTmbk45f2mBn1V1TXRJtYB+grt2a6Bs54xQ+Hr4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=LqEo4Jan/5HivANpRvdFnehU5w+dNmXJe3Bs2UfDt8N90Ez9w/XLvNloD9+aB3sEO aGFVsxqrqpNCXJH55+cnx03TxzMQYYXHXBl9ME/onClsg0f5HRskm+nirs3TKl7DSs stZmLjkPYkcJgsJUCHRs5ySVFkIJbMrbXpcztQq8= Date: Fri, 1 Nov 2024 12:07:17 -0700 From: Andrew Morton To: Asahi Lina Cc: Sergio Lopez Pascual , linux-mm@kvack.org, linux-kernel@vger.kernel.org, asahi@lists.linux.dev, Jia He , Yibo Cai , Kirill A. Shutemov , Catalin Marinas , Asahi Lina , Sergio Lopez Pascual Subject: Re: [PATCH] mm: Fix __wp_page_copy_user fallback path for remote mm Message-Id: <20241101120717.11db30a5abc6378da7910719@linux-foundation.org> In-Reply-To: <20241101-mm-remote-pfn-v1-1-080b609270b7@asahilina.net> References: <20241101-mm-remote-pfn-v1-1-080b609270b7@asahilina.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam09 X-Rspamd-Queue-Id: D74D480015 X-Stat-Signature: np4kphtb6b8j3ufdhmehou6d866dwyyt X-Rspam-User: X-HE-Tag: 1730487985-136468 X-HE-Meta: U2FsdGVkX19KqTcHxBwGAPa4soK1Ubi55r1qSskTaTLpy9CTlYuvZ1U1VjwqWWbqgTUss47LoY/dNIudppLqMX0dWK9s4T6ouBU7eUNL4Wq+1LUnpBovgXuqN1S3mMUHTpo994G2NaMrS5NW+w6dwiAa5/95QLo+6XQcgtfqLcy72IDX6O8I0e8rnSoXe9qlA3voLNfvhCBJ3UE4ucuFALUQJpC3fi0+5nfvzUEN2oVw8wpi+wja3ag9K8T/gvavB5FX3BEho+7Ck/xrhr5VQKNkx/YYhfssnQHrjwwUlOP5QyjBYRfPMRlUZGOF5V8I+60GxbhstxJ/aHfGOcBX0sRV8mO60Yr9mOMfGhsgCrzwyZKHBK4/Y4csxOFNS8BqqRs3ao2h0uQtM2E2UK82lK8lYsg73voBlgY+59w4/1/x/Om3eX8gr/oRh+jHBil5/AuLADPpwtjiffadCM5RwCP/nZ84UdI6E+WiScrfD8PEssT9k7kYwfKtBczj2jqDstJSVQk5fj/falmynENPtrsc/3tgHdfxUKoxFAc462ZNWit403w7XbaDjsE6lbbys3gpPTvqVoUB+hAP6uQ5b5Pe8U7nTWxASzAcH8uHWyqRr9WdwjZCLrBGWf4gV5zLreZ5LOcDXK05Su+8Yn4bIjDxxR+hqmZbCqOX6EMcHwVi+UumfJXYHTUsDsXBmtVCsBhqb2QsWNpnlI6Q37mnJUq0yFsh/+jMR2tvN3pYA77VY3dLBe/5AxYaFMZvBfZjQw6XmNhfWUQ7aF7QxtpJMNYaPBDupxdqcc9bQioYXq9Fxw8FVVH/0OSi0tftaJfeIHBMapFYx1/kcp4pS7msEkQMmzeaCCvGhkTacmZvr8r9wrdIu462CIVVL/jPav21QXEwJqD/fZBwpCRPYCSwVbJC7dwRx7Jmkk1w3k4jL0c89M4SC4b9k6sap5yrF/bA7Yn2Dy+Ec+S1oDm0VEB +qiDTiTh q5KRu3MTbt8C/qoWycMISCOTvMgb/nXnY23DBS1inKlKNc8exCt0cfD4nJUXW/yA8b+M4RhtKknDSiAZA4Qlj71Uu1kzgthgz1xeNEYqzsLPSnc6vsl3upecvZQpu5/KSlP+QrpM662Q6NzPihozzm1h3MPSXz/3jZzo/xpP36SeI/XSOLricFZmHCCB9mAsvWJritIykcZ5XHdVe1q53oP0LZ1v6r34EOGEYawKCN20kUpg8l4wB+xjT9t1OmYkgHK+YVnKMErrvUtQ7GO+boj1cRZUCSCiCd9WRBIu/iDxXMLEmzZV0ugJbf5l71p6AQzoUgk9V3ZX++zfXPhwyTn16gkMFeZxz8t1LJw0oMJnzrTibQwC5mpPBueG2oNwg9BilWc6usPq4xPY= 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 Fri, 01 Nov 2024 21:08:02 +0900 Asahi Lina wrote: > If the source page is a PFN mapping, we copy back from userspace. > However, if this fault is a remote access, we cannot use > __copy_from_user_inatomic. Instead, use access_remote_vm() in this case. > > Fixes WARN and incorrect zero-filling when writing to CoW mappings in > a remote process, such as when using gdb on a binary present on a DAX > filesystem. > > [ 143.683782] ------------[ cut here ]------------ > [ 143.683784] WARNING: CPU: 1 PID: 350 at mm/memory.c:2904 __wp_page_copy_user+0x120/0x2bc > > ... > Thanks. I assume we should backport this into earlier kernels? If so, a Fixes: target is desired, to tell people how far back in time it should be ported. I think it's 83d116c53058 ("mm: fix double page fault on arm64 if PTE_AF is cleared"). > --- a/mm/memory.c > +++ b/mm/memory.c > @@ -3081,13 +3081,18 @@ static inline int __wp_page_copy_user(struct page *dst, struct page *src, > update_mmu_cache_range(vmf, vma, addr, vmf->pte, 1); > } > > + /* If the mm is a remote mm, copy in the page using access_remote_vm() */ > + if (current->mm != mm) { > + if (access_remote_vm(mm, (unsigned long)uaddr, kaddr, PAGE_SIZE, 0) != PAGE_SIZE) > + goto warn; > + } > /* > * This really shouldn't fail, because the page is there > * in the page tables. But it might just be unreadable, > * in which case we just give up and fill the result with > * zeroes. > */ > - if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) { > + else if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) { > if (vmf->pte) > goto warn; > The coding style ends up being unconventional. I made these changes: --- a/mm/memory.c~mm-fix-__wp_page_copy_user-fallback-path-for-remote-mm-fix +++ a/mm/memory.c @@ -3081,18 +3081,20 @@ static inline int __wp_page_copy_user(st update_mmu_cache_range(vmf, vma, addr, vmf->pte, 1); } - /* If the mm is a remote mm, copy in the page using access_remote_vm() */ - if (current->mm != mm) { - if (access_remote_vm(mm, (unsigned long)uaddr, kaddr, PAGE_SIZE, 0) != PAGE_SIZE) - goto warn; - } /* - * This really shouldn't fail, because the page is there - * in the page tables. But it might just be unreadable, - * in which case we just give up and fill the result with - * zeroes. + * If the mm is a remote mm, copy in the page using access_remote_vm() */ - else if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) { + if (current->mm != mm) { + if (access_remote_vm(mm, (unsigned long)uaddr, kaddr, + PAGE_SIZE, 0) != PAGE_SIZE) + goto warn; + } else if (__copy_from_user_inatomic(kaddr, uaddr, PAGE_SIZE)) { + /* + * This really shouldn't fail, because the page is there + * in the page tables. But it might just be unreadable, + * in which case we just give up and fill the result with + * zeroes. + */ if (vmf->pte) goto warn; _ I'll queue this for testing and shall await further review.