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 EA9F241DDEF for ; Wed, 15 Jul 2026 11:18:52 +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=1784114334; cv=none; b=a6oInNN2ygtpsW9UcScmAyngxgX4ET1hrCesUBHhaefTbrE3Cf8Q+t16sLPcwrx9qgosezN0VqW8G8XkNiJZ0xFeJAUYZ3bkDM91sV/oHvECrRapjkzaaKqVIiZk9FjT1MQEjPadgVsMIWgMYGDtU5gbzL1NmOL+v6MwtTzIh44= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784114334; c=relaxed/simple; bh=ls9OD/sb8teEHFiJl0ENCldUadK0ElFq3jDW5TvwNGE=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=NCm/GurSn8dq/ODqKW//he9Nm2RrowerpXRjQG9FSgjcG8qII3E66Je8zcQh2yvEMU+0+JP/oJ8/n7OBK3p/PNVuSPUPEJmJuQ9k3wi2msSWmM2Id8Utt74Jq6DA3nb/+eDEOh4dIB0hlLrpo9aAW2hEKW1OWOp2wtgVX0DDj1A= 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=kI0TpVIx; 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="kI0TpVIx" 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 E511A2F; Wed, 15 Jul 2026 04:18:47 -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 1E56B3F915; Wed, 15 Jul 2026 04:18:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1784114332; bh=ls9OD/sb8teEHFiJl0ENCldUadK0ElFq3jDW5TvwNGE=; h=From:To:Cc:Subject:Date:From; b=kI0TpVIxGBEWAO43VFDHweoOYkZd41CfefGU2+Qtunhu/bRy6aDpG4lv0pCWayjBr tFVXG/99mcN/bgrEqBR4QswnHnnOc0O8wu9Le4Hmdf3oSOYTNOqEJFvSZTsrTVuAOk YILueEg1FbfnhnsvJnRPzabA7lk3QJamrlSC3wUY= From: Dev Jain To: akpm@linux-foundation.org, david@kernel.org, ljs@kernel.org Cc: Dev Jain , liam@infradead.org, vbabka@kernel.org, rppt@kernel.org, surenb@google.com, mhocko@suse.com, kasong@tencent.com, qi.zheng@linux.dev, shakeel.butt@linux.dev, baohua@kernel.org, axelrasmussen@google.com, yuanchu@google.com, weixugc@google.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 0/3] Batch unmap of uffd-wp file folios Date: Wed, 15 Jul 2026 11:18:33 +0000 Message-ID: <20260715111839.1667914-1-dev.jain@arm.com> X-Mailer: git-send-email 2.43.0 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Currently, batched unmapping is supported if: 1) folio is a file folio, not belonging to uffd-wp VMA 2) folio is anonymous and not swapbacked (lazyfree), not belonging to uffd-wp VMA So the cases which are not supported are 1) folio belonging to uffd-wp VMA 2) folio is anonymous and swapbacked It is easy to see that this adds a lot of cognitive load while reading try_to_unmap_one - we need to remember throughout whether nr_pages == 1 or > 1. The uffd-wp handling in try_to_unmap_one is regarding preserving the uffd-wp state for file folios via pte_install_uffd_wp_if_needed (for anon folio, we handle that while constructing the swap pte). Stop special casing on uffd-wp VMAs by simply adding batching support to pte_install_uffd_wp_if_needed. --- This is a split from: https://lore.kernel.org/all/20260526063635.61721-1-dev.jain@arm.com/ mm-selftests pass. I have based this on mm-new since my try_to_unmap_one refactoring changes weren't there in mm-unstable yet. But I suspect this series wouldn't have conflicted there, or conflicted trivially. mm-new currently has Kiryl's uffd-rwp series, which confuses me about the terminology followed by my patchset (and the existing functions): shall I call it uffd-wp bit or uffd bit? Dev Jain (3): mm/memory: move pte_install_uffd_wp_if_needed() into memory.c mm/memory: batch set uffd-wp markers during zapping mm/rmap: batch unmap file folios belonging to uffd-wp VMAs include/linux/mm.h | 4 ++ include/linux/mm_inline.h | 53 ------------------------ mm/memory.c | 84 +++++++++++++++++++++++++++++---------- mm/rmap.c | 6 +-- 4 files changed, 70 insertions(+), 77 deletions(-) -- 2.43.0