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 bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 22256C77B75 for ; Mon, 15 May 2023 23:40:38 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:In-Reply-To:MIME-Version:References: Message-ID:Subject:Cc:To:From:Date:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Owner; bh=5eJZaNVMN31RMDbEpaKi/ddRWPqQAdT1a0J2Fzd/4dM=; b=Bum+B45OJHK7uR borazw8kG+Zwn1dU0YYPfF6d2gQkgJEbYTZBaQyKeypvj9Qkq6NEg3vnUcGe4Al4rFIAlbRXfy7vZ vplCQ61Kyubo2EvHApXkaqKKH5HfdpMvVzeB7E+VUBcI7l69LUYOMW8+cPDY6xrj70Yayp1emVnid HBby7M3Jx4q1Fhvqou4NWj9ON0J4gaaw/ARCC61VJr4tKdxnjbtz4gsNi2Jm0yaa2kgkgn0iC6dJx bfDlKKHmNOqWIwGcVnBcz+WAcNMWFLorE+vwa7WLLZaiEwxAQLR52rzkGd4tc0PdtRi10oJT7aZqJ TqI1A7OHGrmz2Pc2ZAcA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.96 #2 (Red Hat Linux)) id 1pyhnZ-003nb3-1j; Mon, 15 May 2023 23:40:13 +0000 Received: from mail-pl1-x635.google.com ([2607:f8b0:4864:20::635]) by bombadil.infradead.org with esmtps (Exim 4.96 #2 (Red Hat Linux)) id 1pyhnV-003naA-26 for linux-arm-kernel@lists.infradead.org; Mon, 15 May 2023 23:40:11 +0000 Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1ac65ab7432so781355ad.0 for ; Mon, 15 May 2023 16:40:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20221208; t=1684194007; x=1686786007; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=OVvfLhysB+0iy4Qip8pj9vBPM/PIR3p9BpZ5jtYRcn4=; b=oBqogYyzknr4yKRxw88qq274R/foRD0iU/4HpnVOmOYsJgB4y5e/onJdHb/QjS00Ed 3Oz/6ggqipp+vbvqqyTlo1tQwx1kMcflJJiXMvfznOaemX9PTVS3ByDZYXsO8B3ksLSq K+SAlJQ/OtK/9aukf6yJMaDdbGwQU4fdViCLeVkzX/FppvxiLP4wSN7uUSFeQJr3Z1px ATNgFB5RUw9/DrL0w71804OatLnEKT5KVKQAG/AmmN6WkOOzxsj02txLLBVvt8AdYefl sGIk+rEemv4t/FX6klsq7LCxyCh4RfJkGSsJp3CQh4wlg/cyV3A3/pEXzqC9H7JEuWAS gPtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684194007; x=1686786007; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=OVvfLhysB+0iy4Qip8pj9vBPM/PIR3p9BpZ5jtYRcn4=; b=QGJb9T809+HJL1mq13JpsmDu2TbSayph1lFWQmFIIOa0+l291Cswy7pAJRfKqvW9NW paTVqepjv4EgzCu4ZEhnDp8aCiwwBj+T28y+TkeIr2U3yL8QW2LwlO3+OqA0voHTGxAg 68yKDCVlhHO1vEjFm400aMfsNS2LUN+Vj3kx7dno1cfDum42uLzqXC1MAvUp+wULeOa1 QB+eqa4p7QKMu4ftNV6kFK1iUmokmezbvbcmjZ2oYSQO7hRe46Aw9+2dxTEGcBG9u4Qk 1dWX5zXDzNvME9TRZdTFJI4r4vz466ZvtjR4OhSIgkJiu93bz2D4gDsx1wHp9ukNLm0u W0Fg== X-Gm-Message-State: AC+VfDwesDhh6agMbBNH2uFdiFCt05tzrAWudCOnR5jPTzPVH63gzu1Y fnrudeZYKHqsKuhGKSii/Q227w== X-Google-Smtp-Source: ACHHUZ4vbTiXqAKlKE7aAVYgqKytq/j0IcMhHUt5I1ncbJwmtNoHqSAS9l5md56bjM7O5Ol8rpfclQ== X-Received: by 2002:a17:902:ec85:b0:1a6:970f:8572 with SMTP id x5-20020a170902ec8500b001a6970f8572mr17131plg.3.1684194006948; Mon, 15 May 2023 16:40:06 -0700 (PDT) Received: from google.com ([2620:15c:2d3:205:c825:9c0b:b4be:8ee4]) by smtp.gmail.com with ESMTPSA id d6-20020aa78686000000b00640ddad2e0dsm12303707pfo.47.2023.05.15.16.40.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 15 May 2023 16:40:06 -0700 (PDT) Date: Mon, 15 May 2023 16:40:01 -0700 From: Peter Collingbourne To: Catalin Marinas Cc: David Hildenbrand , 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-Disposition: inline In-Reply-To: X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20230515_164009_713043_81FABCFA X-CRM114-Status: GOOD ( 49.24 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=archiver.kernel.org@lists.infradead.org On Mon, May 15, 2023 at 06:34:30PM +0100, Catalin Marinas wrote: > 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. In order to reproduce this bug it is necessary for the swap slot cache to be disabled, which is unlikely to occur during normal operation. I was only able to reproduce the bug by disabling it forcefully with the following patch: diff --git a/mm/swap_slots.c b/mm/swap_slots.c index 0bec1f705f8e0..25afba16980c7 100644 --- a/mm/swap_slots.c +++ b/mm/swap_slots.c @@ -79,7 +79,7 @@ void disable_swap_slots_cache_lock(void) static void __reenable_swap_slots_cache(void) { - swap_slot_cache_enabled = has_usable_swap(); + swap_slot_cache_enabled = false; } void reenable_swap_slots_cache_unlock(void) With that I can trigger the bug on an MTE-utilizing process by running a program that enumerates the process's private anonymous mappings and calls process_madvise(MADV_PAGEOUT) on all of them. > 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). Another problem that I can see with this approach is that it does not respect reference counts for swap entries, and it's unclear whether that can be done in a non-racy fashion. Another approach that I considered was to move the hook to swap_readpage() as in the patch below (sorry, it only applies to an older version of Android's android14-6.1 branch and not mainline, but you get the idea). But during a stress test (running the aforementioned program that calls process_madvise(MADV_PAGEOUT) in a loop during an Android "monkey" test) I discovered the following racy use-after-free that can occur when two tasks T1 and T2 concurrently restore the same page: T1: | T2: arch_swap_readpage() | | arch_swap_readpage() -> mte_restore_tags() -> xe_load() swap_free() | | arch_swap_readpage() -> mte_restore_tags() -> mte_restore_page_tags() We can avoid it by taking the swap_info_struct::lock spinlock in mte_restore_tags(), but it seems like it would lead to lock contention. Peter diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h index 3f8199ba265a1..99c8be073f107 100644 --- a/arch/arm64/include/asm/mte.h +++ b/arch/arm64/include/asm/mte.h @@ -25,7 +25,7 @@ unsigned long mte_copy_tags_to_user(void __user *to, void *from, unsigned long n); int mte_save_tags(struct page *page); void mte_save_page_tags(const void *page_addr, void *tag_storage); -bool mte_restore_tags(swp_entry_t entry, struct page *page); +void mte_restore_tags(struct page *page); void mte_restore_page_tags(void *page_addr, const void *tag_storage); void mte_invalidate_tags(int type, pgoff_t offset); void mte_invalidate_tags_area(int type); diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h index 812373cff4eec..32d3c661a0eee 100644 --- a/arch/arm64/include/asm/pgtable.h +++ b/arch/arm64/include/asm/pgtable.h @@ -1054,11 +1054,11 @@ static inline void arch_swap_invalidate_area(int type) mte_invalidate_tags_area(type); } -#define __HAVE_ARCH_SWAP_RESTORE -static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio) +#define __HAVE_ARCH_SWAP_READPAGE +static inline void arch_swap_readpage(struct page *page) { - if (system_supports_mte() && mte_restore_tags(entry, &folio->page)) - set_page_mte_tagged(&folio->page); + if (system_supports_mte()) + mte_restore_tags(page); } #endif /* CONFIG_ARM64_MTE */ diff --git a/arch/arm64/kernel/mte.c b/arch/arm64/kernel/mte.c index 84a085d536f84..176f094ecaa1e 100644 --- a/arch/arm64/kernel/mte.c +++ b/arch/arm64/kernel/mte.c @@ -38,15 +38,6 @@ EXPORT_SYMBOL_GPL(mte_async_or_asymm_mode); static void mte_sync_page_tags(struct page *page, pte_t old_pte, bool check_swap, bool pte_is_tagged) { - if (check_swap && is_swap_pte(old_pte)) { - swp_entry_t entry = pte_to_swp_entry(old_pte); - - if (!non_swap_entry(entry) && mte_restore_tags(entry, page)) { - set_page_mte_tagged(page); - return; - } - } - if (!pte_is_tagged) return; diff --git a/arch/arm64/mm/mteswap.c b/arch/arm64/mm/mteswap.c index 70f913205db99..3fe7774f32b3c 100644 --- a/arch/arm64/mm/mteswap.c +++ b/arch/arm64/mm/mteswap.c @@ -46,21 +46,23 @@ int mte_save_tags(struct page *page) return 0; } -bool mte_restore_tags(swp_entry_t entry, struct page *page) +void mte_restore_tags(struct page *page) { + swp_entry_t entry = folio_swap_entry(page_folio(page)); void *tags = xa_load(&mte_pages, entry.val); if (!tags) - return false; + return; /* * Test PG_mte_tagged again in case it was racing with another * set_pte_at(). */ - if (!test_and_set_bit(PG_mte_tagged, &page->flags)) + if (!test_and_set_bit(PG_mte_tagged, &page->flags)) { mte_restore_page_tags(page_address(page), tags); - - return true; + if (kasan_hw_tags_enabled()) + page_kasan_tag_reset(page); + } } void mte_invalidate_tags(int type, pgoff_t offset) diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h index 5f0d7d0b9471b..eea1e545595ca 100644 --- a/include/linux/pgtable.h +++ b/include/linux/pgtable.h @@ -793,8 +793,8 @@ static inline void arch_swap_invalidate_area(int type) } #endif -#ifndef __HAVE_ARCH_SWAP_RESTORE -static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio) +#ifndef __HAVE_ARCH_SWAP_READPAGE +static inline void arch_swap_readpage(struct page *page) { } #endif diff --git a/mm/page_io.c b/mm/page_io.c index 3a5f921b932e8..a2f53dbeca7b3 100644 --- a/mm/page_io.c +++ b/mm/page_io.c @@ -470,6 +470,12 @@ int swap_readpage(struct page *page, bool synchronous, } delayacct_swapin_start(); + /* + * Some architectures may have to restore extra metadata to the + * page when reading from swap. + */ + arch_swap_readpage(page); + if (frontswap_load(page) == 0) { SetPageUptodate(page); unlock_page(page); diff --git a/mm/shmem.c b/mm/shmem.c index 0b335607bf2ad..82ccf1e6efe5d 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -1784,12 +1784,6 @@ static int shmem_swapin_folio(struct inode *inode, pgoff_t index, } folio_wait_writeback(folio); - /* - * Some architectures may have to restore extra metadata to the - * folio after reading from swap. - */ - arch_swap_restore(swap, folio); - if (shmem_should_replace_folio(folio, gfp)) { error = shmem_replace_folio(&folio, gfp, info, index); if (error) _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel