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 C896DC77B7D for ; Mon, 15 May 2023 17:34:41 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1D5E6900004; Mon, 15 May 2023 13:34:41 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 18615900002; Mon, 15 May 2023 13:34:41 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 07616900004; Mon, 15 May 2023 13:34:41 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id EAD9C900002 for ; Mon, 15 May 2023 13:34:40 -0400 (EDT) Received: from smtpin28.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay06.hostedemail.com (Postfix) with ESMTP id 91A96AF3D7 for ; Mon, 15 May 2023 17:34:40 +0000 (UTC) X-FDA: 80793189120.28.694FCCE Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf29.hostedemail.com (Postfix) with ESMTP id D8F9612000C for ; Mon, 15 May 2023 17:34:37 +0000 (UTC) Authentication-Results: imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684172078; 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: in-reply-to:in-reply-to:references:references; bh=8p+ihgkPcPd2D3/3WODxI3pDEcclMK1kAB3O4bitP2M=; b=gJsHRNWgEpntRikmfFzvQus0IWXDRFcyeLPC59fM1pFbA/3S2rsreJmmR/tW1LCmAgeTgQ gdmb1WdhK7s90tEor3XvJhXUTwdM3YszXNnQn7jweS1NZgTRKR/91lz/YY6gxlwfUbfq2D We6eZmM9QUX3sMHSbJ9ZSaQ8Hpg4YLM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684172078; a=rsa-sha256; cv=none; b=20WxD5G5TO/Pkuao3Ik5Gf5hsA00po3FMeJKftI/QG49jZ3Xp3JdunWxuzhmey/1cVtKlh ixl/2bhJfbqQn9mpvijwdvwMSgE1jR8YQlyShw2MqLTarmhIuoKdaEEBN6CkhRmLlcOHpS wfBeXqTQe5hHn/dPv/7LdqPWzHm1FeQ= ARC-Authentication-Results: i=1; imf29.hostedemail.com; dkim=none; spf=pass (imf29.hostedemail.com: domain of cmarinas@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=cmarinas@kernel.org; dmarc=fail reason="SPF not aligned (relaxed), No valid DKIM" header.from=arm.com (policy=none) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id DBE0B62DBE; Mon, 15 May 2023 17:34:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 6F0F4C4339B; Mon, 15 May 2023 17:34:33 +0000 (UTC) Date: Mon, 15 May 2023 18:34:30 +0100 From: Catalin Marinas To: David Hildenbrand Cc: Peter Collingbourne , Qun-wei Lin =?utf-8?B?KOael+e+pOW0tCk=?= , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "surenb@google.com" , Chinwen Chang =?utf-8?B?KOW8temMpuaWhyk=?= , "kasan-dev@googlegroups.com" , Kuan-Ying Lee =?utf-8?B?KOadjuWGoOepjik=?= , Casper Li =?utf-8?B?KOadjuS4reamrik=?= , "gregkh@linuxfoundation.org" , vincenzo.frascino@arm.com, Alexandru Elisei , will@kernel.org, eugenis@google.com, Steven Price , stable@vger.kernel.org Subject: Re: [PATCH 1/3] mm: Move arch_do_swap_page() call to before swap_free() Message-ID: References: <20230512235755.1589034-1-pcc@google.com> <20230512235755.1589034-2-pcc@google.com> <7471013e-4afb-e445-5985-2441155fc82c@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7471013e-4afb-e445-5985-2441155fc82c@redhat.com> X-Rspamd-Queue-Id: D8F9612000C X-Stat-Signature: wdsk6eghnmbzzn64czkyfwkjmy1na8js X-Rspam-User: X-Rspamd-Server: rspam09 X-HE-Tag: 1684172077-57001 X-HE-Meta: U2FsdGVkX1+xB/Vi1bPC6219UmSKeA08k4VT0xSNWWQLrhX5NOzI7ocoys+wsSQvfm/UL1AtMxApQoTfVdIGu1qDgSAJzNaA3jnwpLBKATb8BDhbPxqrPhFRM/8EJyXz+spqpdqH/E0XQv3SWVCxXxrqeEpUC+VQ/rk+EqS8NEj22STewmxXZ1pO3ED+aG6SqHvXj4eYkSGv396KH/D2qwrQJErDAY5O9dDd2bYhIS5jOfEWru5CVQjYa6YmHOiQEAONviKAurwcaCzVnwfbq1PWyo70cg225Mjg+sALJXknhciUpoz5kCs3HlOyS/W+nBfxfm8CFxUCmx6LJ96V8EnetWTU4d4TS4n+lAfO4fBDSTIZyXqjcss1xubM2zOzMxowqK1kh4r0oENdh2ggqeUa9JnDbFvm3KOtxR36dspQFG3i0kYNFRvoxyCAuaYPH2PEvS7Ypbx1PLyqTcmNpmOJDxCex9LBIdTBYXRw4SMuz4EBd4k6xgAPW1CVeBABArXc10sXkFElADjdLOzVkcyFqgSHfgg6wBuML8tgkskm5lnt/0o8NwTEFbO1TX+zLTAF14QVGyV0uMhl22CudqVUsuw7/+vPg5wMEjJRQnENY33CLsFLUmZx0KNk/pc9dOz9aofXDwUoToNRX6SIM6+bnz5vsLvs2568sGKOoRS+berEWQO8zdHb7Y9B9z+WcWZkAe974q+zc6M7nynoQy2vS6OdEorvI1eei0sOCsb3OR9mmNjUzebSCJKm3LzPm6NZAB9ACRHA3q90YN6pXzTcVVW8kKCc3gABaNTFL/8icSOd23f7f8NTnU73c4kFD/A1XUwcxcVmnWzBA+9cssJi+R9YxePoD2WaQzPFrnK2mFEUBfMzKwsK6dnYMg+UPvBHL8TnaPR1KbvYkD3OZZLEgiYuo5XD8Ke4/3++T0wwuuB0ZQ4OBrFdF6qA+2SHz/Us+qd95hHsXFqhiFo j8QM0z7w ggnQHo3mi0kjt/JDZZ+ZBSy2jN/70cA41FJW15FCSzh/Z/Ekq+EMqdCv6aYvhBb+R7l34RlHIUWlXRF36AMeU7vVL8188oxM2d2CYzdtmDeaOdMDtb76377tN48IN+f4LhjCZgSFNvnX0iFGLaTWcLk7K9v7K3GHzQ6aApzs7oIgLq2NraD7fzh2GSWYjQRLxaku27BbNHB73WT/0OtRfnwcUsLbU6rFEpCFCNUH3WPLuQfLtr1Nh02TapHMuxgBWRGTmpUzYokpe/9N3xwl5b4mVL7vmGWS/E03IkDbiyRm9njTMOzoEaEOwoU0/U/KxeWI3SUgssUAKISKh0rqxOG6HjQRzbisgEfOHZ3+hy4LFtaWZAnLORV2Jx9hYO+u97+iccgdn5ovzmlb8ULAksCAXTjK8o2hWLNSzUBpS4eQ8IBYa7tHKTtJJaykI8YR8pMJkm7surnETrp7Bu2RfV/mmBAnD0ktixohrmHrancJEGEll2UR0GyszZyV9gPQPj5iyjgBuef51sUVRDloW/Lay3mMAbhGSbuyiYz3ug/ccx4uT1vibWDUc/c6NI/93RaiG7iBanLce+UNHJZWK0oJbSiLIsQUIELk2AwZKIW5+C5bQ1GHhJU5SMQ== 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: On Sat, May 13, 2023 at 05:29:53AM +0200, David Hildenbrand wrote: > On 13.05.23 01:57, Peter Collingbourne wrote: > > diff --git a/mm/memory.c b/mm/memory.c > > index 01a23ad48a04..83268d287ff1 100644 > > --- a/mm/memory.c > > +++ b/mm/memory.c > > @@ -3914,19 +3914,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > } > > } > > - /* > > - * Remove the swap entry and conditionally try to free up the swapcache. > > - * We're already holding a reference on the page but haven't mapped it > > - * yet. > > - */ > > - swap_free(entry); > > - if (should_try_to_free_swap(folio, vma, vmf->flags)) > > - folio_free_swap(folio); > > - > > - inc_mm_counter(vma->vm_mm, MM_ANONPAGES); > > - dec_mm_counter(vma->vm_mm, MM_SWAPENTS); > > pte = mk_pte(page, vma->vm_page_prot); > > - > > /* > > * Same logic as in do_wp_page(); however, optimize for pages that are > > * certainly not shared either because we just allocated them without > > @@ -3946,8 +3934,21 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > pte = pte_mksoft_dirty(pte); > > if (pte_swp_uffd_wp(vmf->orig_pte)) > > pte = pte_mkuffd_wp(pte); > > + arch_do_swap_page(vma->vm_mm, vma, vmf->address, pte, vmf->orig_pte); > > vmf->orig_pte = pte; > > + /* > > + * Remove the swap entry and conditionally try to free up the swapcache. > > + * We're already holding a reference on the page but haven't mapped it > > + * yet. > > + */ > > + swap_free(entry); > > + if (should_try_to_free_swap(folio, vma, vmf->flags)) > > + folio_free_swap(folio); > > + > > + inc_mm_counter(vma->vm_mm, MM_ANONPAGES); > > + dec_mm_counter(vma->vm_mm, MM_SWAPENTS); > > + > > /* ksm created a completely new copy */ > > if (unlikely(folio != swapcache && swapcache)) { > > page_add_new_anon_rmap(page, vma, vmf->address); > > @@ -3959,7 +3960,6 @@ vm_fault_t do_swap_page(struct vm_fault *vmf) > > VM_BUG_ON(!folio_test_anon(folio) || > > (pte_write(pte) && !PageAnonExclusive(page))); > > set_pte_at(vma->vm_mm, vmf->address, vmf->pte, pte); > > - arch_do_swap_page(vma->vm_mm, vma, vmf->address, pte, vmf->orig_pte); > > folio_unlock(folio); > > if (folio != swapcache && swapcache) { > > > You are moving the folio_free_swap() call after the folio_ref_count(folio) > == 1 check, which means that such (previously) swapped pages that are > exclusive cannot be detected as exclusive. > > There must be a better way to handle MTE here. > > Where are the tags stored, how is the location identified, and when are they > effectively restored right now? I haven't gone through Peter's patches yet but a pretty good description of the problem is here: https://lore.kernel.org/all/5050805753ac469e8d727c797c2218a9d780d434.camel@mediatek.com/. I couldn't reproduce it with my swap setup but both Qun-wei and Peter triggered it. When a tagged page is swapped out, the arm64 code stores the metadata (tags) in a local xarray indexed by the swap pte. When restoring from swap, the arm64 set_pte_at() checks this xarray using the old swap pte and spills the tags onto the new page. Apparently something changed in the kernel recently that causes swap_range_free() to be called before set_pte_at(). The arm64 arch_swap_invalidate_page() frees the metadata from the xarray and the subsequent set_pte_at() won't find it. If we have the page, the metadata can be restored before set_pte_at() and I guess that's what Peter is trying to do (again, I haven't looked at the details yet; leaving it for tomorrow). Is there any other way of handling this? E.g. not release the metadata in arch_swap_invalidate_page() but later in set_pte_at() once it was restored. But then we may leak this metadata if there's no set_pte_at() (the process mapping the swap entry died). -- Catalin