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 768C1E6F08C for ; Fri, 1 Nov 2024 21:19:03 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AC6416B009F; Fri, 1 Nov 2024 17:19:02 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A76746B00A0; Fri, 1 Nov 2024 17:19:02 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 964A46B00A1; Fri, 1 Nov 2024 17:19:02 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 7891D6B009F for ; Fri, 1 Nov 2024 17:19:02 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id D2A528047D for ; Fri, 1 Nov 2024 21:19:01 +0000 (UTC) X-FDA: 82738791030.28.DD66EA2 Received: from mail.marcansoft.com (marcansoft.com [212.63.210.85]) by imf21.hostedemail.com (Postfix) with ESMTP id 106A71C0008 for ; Fri, 1 Nov 2024 21:18:04 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=asahilina.net header.s=default header.b=kkEv+4Ow; spf=pass (imf21.hostedemail.com: domain of lina@asahilina.net designates 212.63.210.85 as permitted sender) smtp.mailfrom=lina@asahilina.net; dmarc=pass (policy=quarantine) header.from=asahilina.net ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1730495807; 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=CCh5IqSqKWlYf3H0QWiccP98Q1+C7ls2PcHnh7/4mZQ=; b=8hjpXqgsHSYiwcHvONHPJ3P9vdVf8Ec8f834lfLuTeUDNH4/3GgxJSgyQxAPHQ0vtP7lRN qKAtGLC/deQHPNwTsoMSeh7LdaUcjfhdx/LEFhlTYhRtKeQYVzcas1dY5Mf3yOLT2lmvcs uAYrmbn/dxwMlUtIMLxEsfZLS75hvSI= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1730495807; a=rsa-sha256; cv=none; b=gk86Reu60JEyyOvMSEwVKMVLj03tRI+2rpMk9+pBbBFDhE7fyWubsD+sSxwZOheMW2jl0p z53NslM8yQJoxUNF1TIxe0MuQCtyr4punDZmVNguGD80SB2OtmVMP5nx24sQRLB/hAM9OH shbxP9TzXtJUAwy9B3VE1SCW1IazqEs= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=asahilina.net header.s=default header.b=kkEv+4Ow; spf=pass (imf21.hostedemail.com: domain of lina@asahilina.net designates 212.63.210.85 as permitted sender) smtp.mailfrom=lina@asahilina.net; dmarc=pass (policy=quarantine) header.from=asahilina.net Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: lina@asahilina.net) by mail.marcansoft.com (Postfix) with ESMTPSA id A1DE34346C; Fri, 1 Nov 2024 21:18:55 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=asahilina.net; s=default; t=1730495936; bh=6xaWDHK0ZNyN36LFqzUXQY5DIxzZYmaCpRo5bz9ox+E=; h=Date:Subject:To:Cc:References:From:In-Reply-To; b=kkEv+4OwzBsXQXmszD5kLkRBzfigfXURZGkf91dJixrpf0LG3xV2OheANLBmrKZ+J 2ZQc82ksGX8+ReUzooti37XhXfx4gTT0rL8Ya4JrMSKwmSyKh8G98ibyTwwfjnkNu8 CPujMMIU5HPWrZYc4RaCyEQNo/FgB5r+lOgpfmwOppSo+TCxU7lbs1f0aqhuOWCAQJ nSp9qIjHXyhaM2ZWjImRcSgGFK+Qtd5m3SICc9kPe///gov44G5mo53yfrD0fL4T+d ktkiejuRhmaNxii+tH/Fzt74bcxml9vena+omOIj5kzlbtWlDd1l/rfNbEVoEtvk/9 7pM6XMS867WIQ== Message-ID: <251d19c0-f788-4291-a4b3-d6f8a9b3b4f1@asahilina.net> Date: Sat, 2 Nov 2024 06:18:54 +0900 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] mm: Fix __wp_page_copy_user fallback path for remote mm To: Andrew Morton 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 References: <20241101-mm-remote-pfn-v1-1-080b609270b7@asahilina.net> <20241101120717.11db30a5abc6378da7910719@linux-foundation.org> Content-Language: en-US From: Asahi Lina In-Reply-To: <20241101120717.11db30a5abc6378da7910719@linux-foundation.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 106A71C0008 X-Stat-Signature: hwm6wkjj18c6hnhs79ptetniemwnwk9h X-HE-Tag: 1730495884-237056 X-HE-Meta: U2FsdGVkX1/p3wjNUh0e5m+3VM2obHiw12DUy15tZdJfDzkCYlvY8gcJNyJy9PMV1vGmV077lHu05Ls1DIFVNCDttklFyjTGI/7oqi09+P3Jhzxk3YoIgn5kcUH3TlkG4i6ikMXRlAZnAw65OkgcXX4/iiXKrVx2t5ZbMOWev3MAvP49Ye3I6f3najKdZ32gjifxizCEfwchLCG8s4/scDkVFwMmXlD16FiB0z6RhWeR3RB8J1brLUoBLxnskQ/5f/bI49+HeQEtiGrRD1lRu3YqeCfHFQ3r3V6f8ag88P+b1HwwyCmRZlBTBycbr3wvri67rNQBxbfsNpUSEe5dzs4ztV5QeTh/I6pu1CpfA+AtvBJM3nNHi176l7QGTiZxdG5+ANJwrZWu7ik23PfLHgws9DL0ujuhTxDAYpJW+eA36COOvc8TuuD3qLJSH98bMSx1S8g5Lc3P7dpM0Sb4s/1n4LmxHIMU0jXfgq05YC/IpXBR+iAFbi6dI6PMfjgGDVd9+Xu6PIAyDsqPqrFiITvjxzJLtAqVO1HhaXNiiHPr8AKqQyEh1fVVutk+M0CrYGsKTH6HWXCC9NvMEkMS1/U07D2h8npD3B/zY4vhIGlt2qSUzv1jA72ykHrb/GQdpdO0b4UOisS03vypUHmofrl69fn6Nk1kzK0PRMHcuHSGEtEmiDq5/EJiX5pbE/SWbGvf+p58BvqGQW1tvjoY98Xox9oVJmYhUAd43NzmOTQhs6JZ8EQMRMohnPBxd9KGf9GxLUJ97fxxsDxXQPV7n310GPe1kRz76/ykzKXfZBwbKufd57Iz0KsSQFntacqqP3x6E1peQTlBtdlggtbmLtnNj8At6uM/F80NBRKnrCwnKlir3ILpbxZ21RLu8ytvXaBNIUGHqoNMg0acNsMSaXsJXffBOszls45CTDP8OZrX1RZrefx/K6YP+fmp2JQGwnQ6Ufi2fxcQQas0jFI k92/gYEF botYxjSYcF5ospuGvtvCqKRpmMCuuMuaPA2zIAlCFupK/Vjl/XV3kGGiqir9bL2HUTQsNgsjqpu12z629xmf6YtglK2Lnz3UhcMpaspguuDouUEDID5dNhkcA9tsYUb0CA79pYIttnC29Zw4QmKOj7gKMquJEotRJCdM8TVYiOmII69vNixbPRise4o7q4eTbn3QSCJq4lP3CARYgZ90HTII0/FIQQAC7WFccdttmSNhWDCeLnIIn3v4hY1IpKLT5Lh6tqBFbVdzhv/hubeLz4gnlCxylHekPn9gIpqF1xnmaC6DUXC7JN7/3dc2pybQfuk/J9vQocPI1QzpKL+yTv/dippLSQvgdIhoEB0Y0x/o2vR306iihWcgrZr61ZHAC3f4C 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 11/2/24 4:07 AM, Andrew Morton wrote: > 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 so? I'm not sure how back the bug goes though, possibly a long time... > I think it's > > 83d116c53058 ("mm: fix double page fault on arm64 if PTE_AF is cleared"). That doesn't sound right. The old code prior to the patch still had the __copy_from_user_inatomic() fallback path so it should still have the same problem. That fallback goes back to: 6aab341e0a28 ("mm: re-architect the VM_UNPAGED logic") But the ptrace code back then doesn't seem to be using that codepath at all, so that's meaningless. I think this is the proper tag: 3565fce3a659 ("mm, x86: get_user_pages() for dax mappings") That's when GUP started working for DAX mappings at all, and if my reading of the code is correct, at that point do_wp_page() was only grabbing the struct page for normal pages to pass to wp_page_copy() (triggering the fallback path for DAX mappings). The code has moved around a lot today but has the same logic, so I think it's been broken since then. Should I resend it with the Fixes tag? > > >> --- 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. > ~~ Lina