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 01000C77B7C for ; Sat, 13 May 2023 03:30:04 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 464796B0071; Fri, 12 May 2023 23:30:04 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 414C46B0072; Fri, 12 May 2023 23:30:04 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 2B50B6B0074; Fri, 12 May 2023 23:30:04 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 1C1DB6B0071 for ; Fri, 12 May 2023 23:30:04 -0400 (EDT) Received: from smtpin04.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id DEF32120774 for ; Sat, 13 May 2023 03:30:03 +0000 (UTC) X-FDA: 80783803086.04.6C2F150 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf14.hostedemail.com (Postfix) with ESMTP id BA139100003 for ; Sat, 13 May 2023 03:30:00 +0000 (UTC) Authentication-Results: imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=g87yprI8; spf=temperror (imf14.hostedemail.com: error in processing during lookup of david@redhat.com: DNS error) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1683948601; 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=AjyiA8CSsNyrBFAulIeEup4nb5qDAbNqRQ7zOVhw7pM=; b=jv77CqmV9JY7KsWDnXG0SNZobQmjjlbP06HhfzChZWurQuKOUhCV42vgYsLAFRZ/VlBGqh l+eNCun9NPNIezu87Zr6f/OPr4xFo60ckS1D2mY3S+QIfmemgwEvmDflsOSsxKitfE6aeo MP4jrbOKN5F8TQ2mebPc5y9wPBoL+fM= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1683948601; a=rsa-sha256; cv=none; b=WSAmHfDYxXd5hNJDhZRv1d2Dk1Sieaxnn/I4r01YBbHnllJrtarbU/Cx2K+u0S+ol76hMk HDdMM2ipwHy/+OjFJaIaS8ZeOZZTfhz3VTTSCqmJV383xnrx61Y1IObx6OOEiUwbQlyNiE 18/WzzEqUHCrtlb68VAzyDp43iSDEnI= ARC-Authentication-Results: i=1; imf14.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=g87yprI8; spf=temperror (imf14.hostedemail.com: error in processing during lookup of david@redhat.com: DNS error) smtp.mailfrom=david@redhat.com; dmarc=pass (policy=none) header.from=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683948600; h=from:from: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=AjyiA8CSsNyrBFAulIeEup4nb5qDAbNqRQ7zOVhw7pM=; b=g87yprI8jxFz1HXGMNpvKdPY4NwI7sw8lyFQzd3pzlHpR1qeqMaD/WU+x+H7uUy7qiZlz2 9GE6YMDNiaUQbeCCCn6cJthC7GRSKUiaGQvMihLOI4LtXlz7fBLaJX3kDzAnRBMXqvoErY DtQSMGwv2XZVedWJI/TXrAiKVOqimUQ= Received: from mail-qk1-f200.google.com (mail-qk1-f200.google.com [209.85.222.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-164-sIN6wuyWMWSvFpKUJB69Rg-1; Fri, 12 May 2023 23:29:56 -0400 X-MC-Unique: sIN6wuyWMWSvFpKUJB69Rg-1 Received: by mail-qk1-f200.google.com with SMTP id af79cd13be357-7516df3c3ccso664075285a.1 for ; Fri, 12 May 2023 20:29:56 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683948596; x=1686540596; h=content-transfer-encoding:in-reply-to:subject:organization:from :content-language:references:cc:to:user-agent:mime-version:date :message-id:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=AjyiA8CSsNyrBFAulIeEup4nb5qDAbNqRQ7zOVhw7pM=; b=IGdfDj7KJNEVO/JeXEXXAQuw9UhxI06x8NL7ir9fgquFcwuw/4gGCjCJ+KGopr/HsJ wvxm8kS4hnbjJjKiT+wDP8FRB0a4ydQG5q1Kb0A8esljy2gmkkR9cgOh7oYhDHIR6NDo b5dMpf3+fqavP1uPrt/sT+s3luVKrhiSvOg/fAm9JGvZ3rNRSMfYNgmWWmUdtW2g7Fiv CIBprpvqwmooNpjo1sDZqr3cy6tM1Gega+KpfPqD0w4dUkzFBwte8lfh/X21EiW5CHHf Og3QO2q+N2VnEz6wMxxBbDe300IEI7lEvuxDA9GdjR8ZChuY1WTCZ1D4AsrHQUjjW0XO rCUw== X-Gm-Message-State: AC+VfDwzQ54Mpe6QYUP1o3TI3oLqdQ477GPgm78VirgRceBdV0fjSbrv hgSlYDAuIfxKtR5YqrUwlU2pEacPmEnOxVV29D4CogwrTfh8Uh9m2orVgprhz11ZcWrnytnRPjP rt7e0oIugFSo= X-Received: by 2002:ac8:580e:0:b0:3ef:52ac:10d2 with SMTP id g14-20020ac8580e000000b003ef52ac10d2mr43450060qtg.43.1683948596196; Fri, 12 May 2023 20:29:56 -0700 (PDT) X-Google-Smtp-Source: ACHHUZ5uKjxFXSk2VXZahSFRKvmzrBM3NShgEQwno70kldYsCKVJwIg1m82AD+GP0jDRamMLZ8k86w== X-Received: by 2002:ac8:580e:0:b0:3ef:52ac:10d2 with SMTP id g14-20020ac8580e000000b003ef52ac10d2mr43450038qtg.43.1683948595851; Fri, 12 May 2023 20:29:55 -0700 (PDT) Received: from ?IPV6:2603:7000:3d00:1816::1772? (2603-7000-3d00-1816-0000-0000-0000-1772.res6.spectrum.com. [2603:7000:3d00:1816::1772]) by smtp.gmail.com with ESMTPSA id l20-20020ae9f014000000b00755951e48desm5710604qkg.135.2023.05.12.20.29.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 12 May 2023 20:29:55 -0700 (PDT) Message-ID: <7471013e-4afb-e445-5985-2441155fc82c@redhat.com> Date: Sat, 13 May 2023 05:29:53 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 To: Peter Collingbourne , Catalin Marinas Cc: =?UTF-8?B?UXVuLXdlaSBMaW4gKOael+e+pOW0tCk=?= , linux-arm-kernel@lists.infradead.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, "surenb@google.com" , =?UTF-8?B?Q2hpbndlbiBDaGFuZyAo5by16Yym5paHKQ==?= , "kasan-dev@googlegroups.com" , =?UTF-8?B?S3Vhbi1ZaW5nIExlZSAo5p2O5Yag56mOKQ==?= , =?UTF-8?B?Q2FzcGVyIExpICjmnY7kuK3mpq4p?= , "gregkh@linuxfoundation.org" , vincenzo.frascino@arm.com, Alexandru Elisei , will@kernel.org, eugenis@google.com, Steven Price , stable@vger.kernel.org References: <20230512235755.1589034-1-pcc@google.com> <20230512235755.1589034-2-pcc@google.com> From: David Hildenbrand Organization: Red Hat Subject: Re: [PATCH 1/3] mm: Move arch_do_swap_page() call to before swap_free() In-Reply-To: <20230512235755.1589034-2-pcc@google.com> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: BA139100003 X-Rspam-User: X-Rspamd-Server: rspam06 X-Stat-Signature: bxk55ceyh98td6izdae8byttkd6epf69 X-HE-Tag: 1683948600-937931 X-HE-Meta: U2FsdGVkX1+kRhK0qtWa0LsnHUm8ZBJ02Ta74qBZeJSZuQV+q8s113+bNnK87Z0BL6VIRNmUq9oo+23kJ/CzRwpe7QQDArmraYvRidJrJiI3ewl/3hvuiryz+93jNC5xV3dxFn5GuUvzNucbHG76vb1bHujC5YAS+il51Nek9X9S62prC1IxeSYc3+Qpc1Eq6v164PyobgrBYknC5lJLa5wDje0XjHgTkHsB7HxNnriiCYddhVPIRex0/zjjIfvg8fa814h7qTOHIEiilbFPCLY0FEnn0vIpEvZUK4LkL6RTRbxNfRXt7knM+KVpQV2h3aveh1SmJyMYOJVLWVAjGBtd+cQNWWzsneqgqmJ1JTJWfyihJu578kaRAWk9am3EPEk86+N9JDlNvQEmgnAg8ABjZySW5Q8flqEARka0bMsJitVN5i7AiUlZrrxLqOAsqJIPRD2e+/l8tioCMENiD1OwMRwrrYotSOpGGRNYkISoYp+Nn3CSL0UXh4/UupU1TdnNYB9M7uE3GDSp+VWQ0NAO3Uvvkpum2Tz5BR95cd/0JSlJF7Nezacymqs3Z9KR8HfInvhoBCeZBG04upmzwtQZ3CTG8T/MusJcos/AIIDCOvV0l88IsA5BQnqtJ9C0hh8G/SvcnZvXkMSg+F+aHQ1Z5V6F0TMjqKbqaljT//pO9jb/MmcSEPN7B84V+GMceB4qEsJWm0fxSamxzFpB4/9/Vf15ATo9pdJ5J1PLPFe8cHvZeSd2F1z6V7LzJxnwPZRh4RGIx/NuOU31nmcSMX7vUpqsHhaFbxYja9jKzpPtT9wOCJHrO/iSedJxSRkCizFdOj+rl/q+57GIYpvOAAnAoHFykJ7zIWMbRmqPkXbpvfoLvKcGG4Ok/uXqjI2YbGNEKWuf7U+azvREdeZ5EbLZ9UEX67h6b8zmtg8ty235sJGCxbxGs/5uYt+GT9/Cgxp/hjFAZsKWrOuHPGP 4eIS4jeA DNsPcwS5cQc8sx/lh5nRMp51VtwBC8kNLOhaWafIDZDDTZNAn0opXE+0zVJAaxRtRbyvnTcNlc5xFs910GRV+wCHSuPwDTYY+wM0ouN0SkPxSGAWbiWxyPYpboLwZccgn5J/euLtkIuVf3l03/e73w8ri+zR0L3arHZaz1SiGszj+uYsxMhOIzWYsSKJd3TIYwOqTeZeYk/ktCYT2d/a8kF656/1ML2mWwCEd03b0LEWWuWikktLiTooM2WImf1ZbTnG6HpVptq3mvw6DWYh7mpefXkSVSHNHbZMngIow9g5VjLw2bi8Szbid67Gh9DOu7v7OdR/qWX04PXoiThrpCC7+ER3ZmhmH4cL4YmbihQitTEFCCIaAAWmoz7n6v2jGz+xXIeGmrpFDAzXXHSGVrRo3/QVW6jninrDerQRrUGfKEb1webGdK8FXLCwZTNWbRP/0k6qL+ShbcKj71VmJ5t2AGhRIdWxC01ZcBAs1B8xf98nc8Sn/4A+ZSYGSiH3vD7J4Y0IGHATKsJN055q9YhVF4fsh1DYcxfKvMAeG56CO55SjdPtuLIAqqfTSDDnsPirNCF0pLrwrebb5832jIKYflQuQtpKuvJ3JCMtntp01TMDn38Cstc38gzT0xdZ4/iLPD9Kuap0jOnnAnXaZc7x2YXJq90NpjjPmf7PkRoS5uVw= 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 13.05.23 01:57, Peter Collingbourne wrote: > Commit c145e0b47c77 ("mm: streamline COW logic in do_swap_page()") moved > the call to swap_free() before the call to set_pte_at(), which meant that > the MTE tags could end up being freed before set_pte_at() had a chance > to restore them. One other possibility was to hook arch_do_swap_page(), > but this had a number of problems: > > - The call to the hook was also after swap_free(). > > - The call to the hook was after the call to set_pte_at(), so there was a > racy window where uninitialized metadata may be exposed to userspace. > This likely also affects SPARC ADI, which implements this hook to > restore tags. > > - As a result of commit 1eba86c096e3 ("mm: change page type prior to > adding page table entry"), we were also passing the new PTE as the > oldpte argument, preventing the hook from knowing the swap index. > > Fix all of these problems by moving the arch_do_swap_page() call before > the call to free_page(), and ensuring that we do not set orig_pte until > after the call. > > Signed-off-by: Peter Collingbourne > Suggested-by: Catalin Marinas > Link: https://linux-review.googlesource.com/id/I6470efa669e8bd2f841049b8c61020c510678965 > Cc: # 6.1 > Fixes: ca827d55ebaa ("mm, swap: Add infrastructure for saving page metadata on swap") > Fixes: 1eba86c096e3 ("mm: change page type prior to adding page table entry") I'm confused. You say c145e0b47c77 changed something (which was after above commits), indicate that it fixes two other commits, and indicate "6.1" as stable which does not apply to any of these commits. > --- > mm/memory.c | 26 +++++++++++++------------- > 1 file changed, 13 insertions(+), 13 deletions(-) > > 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? -- Thanks, David / dhildenb