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 BEC1D39524B for ; Tue, 26 May 2026 06:37:45 +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=1779777467; cv=none; b=J3Jb1cpUAQ2EktFXGw4qtdWGhVHAtsXA3cvdm5nSSmo/Z7hB2rnO0rR5eD/MtkFfFaIZyRVPQV0dcQJOGZWEI0Kud9d7v6gxz3MBY/fnTY6murvky+SyxsZ3oYXoRkeGrOLh1w0+hxsValrwJfuel5DeURJbLvTHieqBk7L72QE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779777467; c=relaxed/simple; bh=zI0ZXjJNDDE2exbOQSUMmCQhV1H2PQoQr/8eVWk8agU=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=LvIvGkPsZ66uAG/dP7bf1nFQVtgCCq/NAT6sKhIh/GLl0IX5ZsPu/Fnue/A9S8cufyw1LWgXWKv7c2CvValrlTnOvA82DR2ltDaMhByE4onJ7Ix0gt9/aeXk8Pc9oXoFp3m7CN4ov0odNaFHbbvYybvC7bXi9PTlriueius2S4M= 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=Du4jWa36; 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="Du4jWa36" 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 282DB176B; Mon, 25 May 2026 23:37:40 -0700 (PDT) Received: from a080796.blr.arm.com (a080796.arm.com [10.164.21.51]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 84BC33F7D8; Mon, 25 May 2026 23:37:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1779777465; bh=zI0ZXjJNDDE2exbOQSUMmCQhV1H2PQoQr/8eVWk8agU=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=Du4jWa36TFo6ZfukxGs1dMa72ax9sM52+Jj1iJt0U8pryuzeauPPR5wF5v4tCxP7I X+a0P5222OropDvxeqxuV/0vxOrRAh7U67qf3ZLyvpHp2Mvav20APZrCIvnpumDsuZ /CjS03/SIewtNgerFImmjDNzn7gq7MOsH+WiBSO8= From: Dev Jain To: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org, chrisl@kernel.org, kasong@tencent.com, hughd@google.com, liam@infradead.org Cc: Dev Jain , riel@surriel.com, vbabka@kernel.org, harry@kernel.org, jannh@google.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, qi.zheng@linux.dev, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.com, shikemeng@huaweicloud.com, nphamcs@gmail.com, bhe@redhat.com, youngjun.park@lge.com, baolin.wang@linux.alibaba.com, pfalcato@suse.de, ryan.roberts@arm.com, anshuman.khandual@arm.com Subject: [PATCH v4 05/12] mm/rmap: batch unmap folios belonging to uffd-wp VMAs Date: Tue, 26 May 2026 12:06:28 +0530 Message-Id: <20260526063635.61721-6-dev.jain@arm.com> X-Mailer: git-send-email 2.34.1 In-Reply-To: <20260526063635.61721-1-dev.jain@arm.com> References: <20260526063635.61721-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 install_uffd_wp_pte_if_needed() support batching, but that was left out for the time being, and correctness was maintained by stopping batching in case the VMA the folio belongs to is marked uffd-wp. Now that we have a batched version called cond_install_uffd_wp_ptes, simply call that. folio_unmap_pte_batch() ensures that the original state of the ptes is either all uffd or all non-uffd, so we maintain correctness. If uffd-wp bit is there, we have the following transitions of ptes after unmapping: 1) anon folio: present -> uffd-wp swap 2) file folio: present -> uffd-wp marker We must ensure that these ptes are not reprocessed by the while loop - if the batch length is less than the number of pages in the folio, then we must skip over this batch. The page_vma_mapped_walk API ensures this - check_pte() will return true only if any of [pvmw->pfn, pvmw->pfn + nr_pages) is mapped by the pte. There is no pfn underlying either a uffd-wp swap pte or a uffd-wp marker pte, so check_pte returns false and we keep skipping until we hit a present entry, which is where we want to batch from next. Acked-by: David Hildenbrand (Arm) Signed-off-by: Dev Jain --- mm/rmap.c | 5 +---- 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/mm/rmap.c b/mm/rmap.c index 6a0b43856d6c0..ead031361bc61 100644 --- a/mm/rmap.c +++ b/mm/rmap.c @@ -1965,9 +1965,6 @@ static inline unsigned int folio_unmap_pte_batch(struct folio *folio, if (pte_unused(pte)) return 1; - if (userfaultfd_wp(vma)) - return 1; - /* * If unmap fails, we need to restore the ptes. To avoid accidentally * upgrading write permissions for ptes that were not originally @@ -2288,7 +2285,7 @@ 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.34.1