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 4725F3B3BF5 for ; Mon, 20 Jul 2026 06:55:42 +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=1784530544; cv=none; b=hJA8EE1qmeh69dVw5uPv4r6woSW7SZ0lbcieoRqR5+PAnnSTzezdCg5T73k+nAeLj2eaFox6P7MyMs3YBlLNFS+D1xYrtFfdJCJThtvTwHfrV0mkkQuL21ulQOBLFr6wOdX6dtZgKtlR8U7INFIzeWxvbkgZR77NnFEY4vSCM2g= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784530544; c=relaxed/simple; bh=0uZCBLA/6tv50+Xe48dX0mngoeuzlIGQwQYeLrBh4lY=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=iq8xrbOUDcclKRUeAxF4Sf0UolK3v3lMa4L2bS0xh3OGmLnFugU0PPxA0kARBCFNeIZq/qVreEyn0Za29wtZ8LomYta6AYu8ckeulMyKoqJeR47//OO0cDigEaougHoKgZzvvoCOm0Q9+9/aQ0km6yNt5lzIfyYfIMilFNGWSu8= 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=H0xKn+bn; 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="H0xKn+bn" 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 9A21E1682; Sun, 19 Jul 2026 23:55:37 -0700 (PDT) Received: from cesw-amp-gbt-1s-m12830-01.blr.arm.com (cesw-amp-gbt-1s-m12830-01.blr.arm.com [10.164.195.33]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id ADE583F66F; Sun, 19 Jul 2026 23:55:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1784530541; bh=0uZCBLA/6tv50+Xe48dX0mngoeuzlIGQwQYeLrBh4lY=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=H0xKn+bngtg4BLC2D/vhC7e1XPwe1FrLhGweIhhaXrq2APRtiYOJ14I9r9//8gzcK VUZh22RAI1Mvb8nWOKXE3O+LDiw4sx1GDF+N2MKUILSHon9gU06tmW5csVccIFD84P 2GFw2+TaofMRBayEIOFWiv0g5QJXEjDCFkhZEMnQ= From: Dev Jain To: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org Cc: Dev Jain , kasong@tencent.com, qi.zheng@linux.dev, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, riel@surriel.com, harry@kernel.org, jannh@google.com, lance.yang@linux.dev, ryan.roberts@arm.com, anshuman.khandual@arm.com Subject: [PATCH v2 3/3] mm/rmap: batch unmap file folios belonging to uffd-wp VMAs Date: Mon, 20 Jul 2026 06:55:07 +0000 Message-ID: <20260720065508.2695106-4-dev.jain@arm.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20260720065508.2695106-1-dev.jain@arm.com> References: <20260720065508.2695106-1-dev.jain@arm.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Commit a67fe41e214f ("mm: rmap: support batched unmapping for file large folios") extended batched unmapping for file folios. That also required making pte_install_uffd_wp_if_needed() support batching, but that was left out for the time being. Correctness was maintained by stopping batching if the VMA the folio belongs to is marked uffd-wp. Now that cond_install_uffd_wp_ptes() supports batching, call it with the full batch length and allow folio_unmap_pte_batch() to batch file folios belonging to uffd-wp VMAs. For file folios, if the uffd-wp bit is set, unmapping converts present PTEs into uffd-wp markers. We must ensure that the same PTE range is not reprocessed by the try_to_unmap_one() loop. The page_vma_mapped_walk API ensures this: check_pte() only returns true if any PFN in [pvmw->pfn, pvmw->pfn + nr_pages) is mapped by the PTE. There is no PFN underlying a uffd-wp marker PTE, so check_pte() returns false and the walk skips ahead until it reaches a present entry again. Acked-by: David Hildenbrand (Arm) Signed-off-by: Dev Jain --- mm/rmap.c | 6 ++---- 1 file changed, 2 insertions(+), 4 deletions(-) diff --git a/mm/rmap.c b/mm/rmap.c index abeb8e7ceba17..56eaddfc610b1 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1968,9 +1968,6 @@ static inline unsigned int folio_unmap_pte_batch(struct folio *folio, if (pte_unused(pte)) return 1; - if (userfaultfd_protected(vma)) - return 1; - /* * If unmap fails, we need to restore the ptes. To avoid accidentally * upgrading write permissions for ptes that were not originally @@ -2348,7 +2345,8 @@ static bool try_to_unmap_one(struct folio *folio, struct vm_area_struct *vma, * we may want to replace a none pte with a marker pte if * it's file-backed, so we don't lose the tracking info. */ - cond_install_uffd_wp_ptes(vma, address, pvmw.pte, pteval, 1); + cond_install_uffd_wp_ptes(vma, address, pvmw.pte, pteval, + nr_pages); /* Update high watermark before we lower rss */ update_hiwater_rss(mm); -- 2.43.0