From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id CFE8E28C86C for ; Thu, 9 Jul 2026 13:39:13 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783604355; cv=none; b=NjcecrRL6XPdCnChNU+9JTI6NtEh0xCB/OiUZWC8na/klhKwVgG8G9SoVh9QhJBzg8sC+QK3YpNuAMEMUnF1xjG+bv9/chAF8L2TgcM05aVym7GoVy+rY+alerqPy87MfJA5i0zAzN/waEDi3R8+J3dvQCSvA1g5aT2MGfWmsx8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1783604355; c=relaxed/simple; bh=SDJoeU8Reac6famvfbS1+RPrRYH1qwGUWY3op31U2FU=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=eRE1Y5FgkzmMb9H/GlHduE0UDDYARUi258aqAUBl983FsXbtipSPVHJHNlJo+6L1EMUbV3G6SlqS2tkoBqG8GrVV21PGOTG2LsgIJU2FupjH4fLN1XatZnGLLH5olh/AcuiyTI1n8mr8pZA45dm2lHL8GZjhkr6XEt34iFwuD0E= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=PZNre4gv; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="PZNre4gv" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id EE0831684; Thu, 9 Jul 2026 06:39:08 -0700 (PDT) Received: from [10.164.148.40] (MacBook-Pro.blr.arm.com [10.164.148.40]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 24C2F3F85F; Thu, 9 Jul 2026 06:39:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1783604353; bh=SDJoeU8Reac6famvfbS1+RPrRYH1qwGUWY3op31U2FU=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=PZNre4gvmYW3bEFLr803+SQHvfsQuLzp1wwpgpIQ35IKVZdDq3mGMUqmeZIz8Tl7b LxyhJUm6A3NbLHZs1yn6eJJZ05V0EnPIvBku48ZURTMmMgxCDUQOsFb7HHP7/H3Xem 62huO4i/sIEOCuZh5GM9f18Cl40WhTLJu+p9+85w= Message-ID: <994e2971-c764-45ab-914d-5c265c263b9b@arm.com> Date: Thu, 9 Jul 2026 19:09:06 +0530 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH 4/5] mm/rmap: refactor anon swapbacked folio unmap in try_to_unmap_one To: "David Hildenbrand (Arm)" , akpm@linux-foundation.org, ljs@kernel.org, muchun.song@linux.dev, osalvador@suse.de Cc: riel@surriel.com, liam@infradead.org, vbabka@kernel.org, harry@kernel.org, jannh@google.com, lance.yang@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org, ryan.roberts@arm.com, anshuman.khandual@arm.com References: <20260707121128.373192-1-dev.jain@arm.com> <20260707121128.373192-5-dev.jain@arm.com> <1221180d-6217-401f-a479-3a5d9684659e@kernel.org> Content-Language: en-US From: Dev Jain In-Reply-To: <1221180d-6217-401f-a479-3a5d9684659e@kernel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 07/07/26 7:56 pm, David Hildenbrand (Arm) wrote: > On 7/7/26 14:11, Dev Jain wrote: >> Refactor anonymous swapbacked folio unmap to ttu_anon_swapbacked_folio(). >> >> No functional change intended. >> >> Signed-off-by: Dev Jain >> --- >> mm/rmap.c | 105 ++++++++++++++++++++++++++++++++---------------------- >> 1 file changed, 62 insertions(+), 43 deletions(-) >> >> diff --git a/mm/rmap.c b/mm/rmap.c >> index 00b571c2a1bab..ade78df5be2bd 100644 >> --- a/mm/rmap.c >> +++ b/mm/rmap.c >> @@ -2113,6 +2113,64 @@ static inline bool ttu_anon_lazyfree_folio(struct vm_area_struct *vma, >> return true; >> } >> > > BTW, no need for the "inline" for most of these functions (applies to other > patches as well). Okay > >> +static inline void set_swp_pte_at(struct mm_struct *mm, unsigned long address, >> + pte_t *ptep, swp_entry_t entry, pte_t pteval, bool anon_exclusive) > > It's confusing that we say "set_swp_pte_at", but the pte_t we was is actually > the old pte. > > Can we instead have a function that creates us a swap_pte from the other data, > and then do the set_pte_at() in the caller? > > static pte_t swp_pte_prepare(...) > { > ... > return swp_pte; > } Okay > >> +{ >> + pte_t swp_pte = swp_entry_to_pte(entry); >> + >> + if (anon_exclusive) >> + swp_pte = pte_swp_mkexclusive(swp_pte); >> + >> + if (likely(pte_present(pteval))) { >> + if (pte_soft_dirty(pteval)) >> + swp_pte = pte_swp_mksoft_dirty(swp_pte); >> + if (pte_uffd_wp(pteval)) >> + swp_pte = pte_swp_mkuffd_wp(swp_pte); >> + } else { >> + /* Device-exclusive entry */ >> + if (pte_swp_soft_dirty(pteval)) >> + swp_pte = pte_swp_mksoft_dirty(swp_pte); >> + if (pte_swp_uffd_wp(pteval)) >> + swp_pte = pte_swp_mkuffd_wp(swp_pte); >> + } >> + >> + set_pte_at(mm, address, ptep, swp_pte); >> +} >> + >> +static inline bool ttu_anon_swapbacked_folio(struct vm_area_struct *vma, struct folio *folio, >> + struct page *subpage, unsigned long address, pte_t *ptep, > > Subpages do not exist :) Ack > >> + pte_t pteval) >> +{ >> + bool anon_exclusive = folio_test_anon(folio) && PageAnonExclusive(subpage); > > const? Okay > >> + swp_entry_t entry = page_swap_entry(subpage); >> + struct mm_struct *mm = vma->vm_mm; >> + >> + if (folio_dup_swap(folio, subpage) < 0) >> + return false; >> + >> + /* >> + * arch_unmap_one() is expected to be a NOP on >> + * architectures where we could have PFN swap PTEs, >> + * so we'll not check/care. >> + */ >> + if (arch_unmap_one(mm, vma, address, pteval) < 0) { >> + folio_put_swap(folio, subpage); >> + return false; >> + } >> + >> + /* See folio_try_share_anon_rmap(): clear PTE first. */ >> + if (anon_exclusive && folio_try_share_anon_rmap_pte(folio, subpage)) { >> + folio_put_swap(folio, subpage); > > I recall I stumbled over this before, but there is no way to undo the > arch_unmap_one(), right? arch_unmap_one -> adi_save_tags is saving tags in an mm related structure. So I don't think there is any need to have a reverse operation in case of unmap failure, since the ADI tags are still there on the page. > >> + return false; >> + } >> + >> + mm_prepare_for_swap_entries(mm); >> + dec_mm_counter(mm, MM_ANONPAGES); >> + inc_mm_counter(mm, MM_SWAPENTS); >> + set_swp_pte_at(mm, address, ptep, entry, pteval, anon_exclusive); >> + return true; >> +} >> + >