The majority of architectures in the kernel defer page table freeing until
an RCU grace period has elapsed, this series converts all remaining
architectures to do so too and eliminates CONFIG_MMU_GATHER_RCU_TABLE_FREE
altogether.

This is important because it enables safe lockless page table walking under
RCU alone.

Doing so allows for reduced lock contention, avoids lock ordering concerns
and enables fast, efficient and correct page table walking as a result.

Additionally it removes a bunch of code and architecture-specific behaviour
which is always a beneficial thing to do.

There has been much recent work on this:

* In 2023 Hugh Dickins RCU-deferred khugepaged page table retraction in
  commit 13cf577e6b66 ("mm/pgtable: add pte_free_defer() for pgtable as
  page").

* Qi Zheng has done most of the work that made this possible starting with
  the critical commit 718b13861d22 ("x86: mm: free page table pages by RCU
  instead of semi RCU").

* Qi then went on to convert a large number of architectures in commit
  e3ecf7c7d082 ("mm: pgtable: convert some architectures to use
  tlb_remove_ptdesc()"), commit 44b079583f7d ("alpha: mm: enable
  MMU_GATHER_RCU_TABLE_FREE") and the series to which it belongs.

* Qi then introduced the important CONFIG_HAVE_ARCH_TLB_REMOVE_TABLE
  option in commit 086498aed3f6 ("mm: convert __HAVE_ARCH_TLB_REMOVE_TABLE
  to CONFIG_HAVE_ARCH_TLB_REMOVE_TABLE config").

* Finally, and critically, Lance Yang then converted the batch allocation
  fallback case to be RCU-safe in commit 1fb3d8c20bfa ("mm/mmu_gather:
  replace IPI with synchronize_rcu() when batch allocation fails").

The work I do here is only possible due to the work Hugh, Qi, Lance and
others have done previously.

An initial task this series addresses is to deposit a freshly allocated PTE
page table and RCU-free the existing PTE page table. Not doing so is
currently safe, but for page table walkers relying on RCU alone, it would
not be.

Additionally, it makes it possible to implement lockless RCU-only page
table walkers which otherwise would have required the PTE PTL.

The changes are largely mechanical - the majority of arches already have
the machinery required to support CONFIG_MMU_GATHER_RCU_TABLE_FREE and
simply needed configuration changes or small implementation changes to
switch over.

However some arches required extra attention - sh-X2, m68k-motorola and
sparc32.

sh-X2 allocates PMDs from the slab allocator and PTEs as normal. Therefore
CONFIG_HAVE_ARCH_TLB_REMOVE_TABLE is set to customise page table freeing
and the LSB is used to encode which page table level is used, with
__tlb_remove_table() doing the right thing depending on this.

This pattern is repeated for m68k-motorola and sparc32 to account for
different page table levels. In each case, the page tables are aligned such
that sufficient bits are available in each case for encoding this
information.

m68k-motorola required the biggest change - since RCU page table freeing
uses call_rcu(), this means page table freeing can arise from softirq
context.

This was fixed with an IRQ-safe spin lock used in both get_pointer_table()
and free_pointer_table().

As part of this change, the logic for allocation of a new pointer table was
separated out into add_pointer_table() to make the locking more obviously
correct.

Finally, sparc32 was similar to m68k-motorola in that locking was required,
however this was already implemented via a spinlock, and only had to be
updated to be IRQ-safe.

Additionally, the nocache pool's bit_map lock was updated to be IRQ-safe
for softirq frees.

Separately, the PTE path can't take mm->page_table_lock from softirq (no mm
there), which is fine because the page reference count transitions are
atomic and fully ordered.

The series finally removes CONFIG_MMU_GATHER_RCU_TABLE_FREE and all related
configurations and code that supported !CONFIG_MMU_GATHER_RCU_TABLE_FREE.

As a result, page table walks can now be performed safely under RCU without
any risk of page tables being freed underneath a walker.

However, this is the only guarantee that this work provides - page table
walkers must still ensure that page table entries are as expected
throughout.

All changes have been build tested. As most of the conversions are simply
utilising existing mechanics that are known to work, this suffices for most
cases.

However those arches where significant changes have been made -
m68k-motorola, sparc32 and sh-X2 - have been tested further.

For each of these a boot test and stress test has been performed - fork 400
children, each mmap()'ing 2 MiB and touching every page then partially
munmap()'ing then exiting to trigger as much page table freeing as
possible.

All were found to be working correctly.

(Note that sparc32 LEON SMP is not possible to emulate.)

v4:
* Updated the 1st patch to allocate a new page table on PTE deposit rather
  than deposit a page table that might currently be being walked by an
  RCU-only page table walker, as per David.

v3:
* Added Kiryl's tag to series (thanks! :)
* Corrected commit message, comment indentation in 11/12 as per Kiryl.
* Corrected 12/12 documentation as per Kiryl.
https://lore.kernel.org/r/20260911-rcu-pagetable-freeing-v3-0-7b8c86103821@kernel.org

v2:
* Updated commit message to reflect CONFIG_MMU dependency for xtensa as per
  Suren.
* Updated 12/12 to correctly describe the new contract re: readers/writes
  as per Kiryl. Also fixed up typos there as per Kiryl, Suren and slightly
  reworded for clarity, and updated commit message to reflect.
* Updated 11/12 to reflect the fact the change is for userland only as per
  Kiryl, also added a note about write locks similarly to 12/12.
* Fixed bug as reported by sashiko for the sparc32 change (10/12) - the
  refcounts are insufficient on their own, so replace the page_table_lock
  altogether with an IRQ-safe spinlock.
https://lore.kernel.org/r/20260908-rcu-pagetable-freeing-v2-0-1f60b64e878e@kernel.org

v1:
https://patch.msgid.link/20260901-rcu-pagetable-freeing-v1-0-5456a81c8212@kernel.org

Signed-off-by: Lorenzo Stoakes (ARM) <ljs@kernel.org>
---
Lorenzo Stoakes (ARM) (12):
      mm/khugepaged: deposit a newly allocated page table on collapse
      mm: enable MMU_GATHER_RCU_TABLE_FREE for most 2-level architectures
      mm: enable MMU_GATHER_RCU_TABLE_FREE for MMU riscv
      mm: enable MMU_GATHER_RCU_TABLE_FREE for MMU arm
      mm: enable MMU_GATHER_RCU_TABLE_FREE for arc, microblaze, xtensa
      mm: enable MMU_GATHER_RCU_TABLE_FREE for sparc64
      mm: enable MMU_GATHER_RCU_TABLE_FREE for m68k-coldfire
      mm: enable MMU_GATHER_RCU_TABLE_FREE for sh-X2
      mm: enable MMU_GATHER_RCU_TABLE_FREE for m68k-motorola
      mm: enable MMU_GATHER_RCU_TABLE_FREE for sparc32
      mm: make userland page table freeing RCU-safe
      mm: change the contract for free_pgtables(), update docs

 Documentation/mm/process_addrs.rst       |   6 ++
 arch/Kconfig                             |   8 --
 arch/alpha/Kconfig                       |   1 -
 arch/arc/include/asm/pgalloc.h           |   6 +-
 arch/arm/Kconfig                         |   1 -
 arch/arm64/Kconfig                       |   1 -
 arch/loongarch/Kconfig                   |   1 -
 arch/m68k/Kconfig                        |   1 +
 arch/m68k/include/asm/mcf_pgalloc.h      |   5 +-
 arch/m68k/include/asm/motorola_pgalloc.h |   9 ++-
 arch/m68k/mm/motorola.c                  | 121 ++++++++++++++++++++-----------
 arch/microblaze/include/asm/pgalloc.h    |   2 +-
 arch/mips/Kconfig                        |   1 -
 arch/parisc/Kconfig                      |   1 -
 arch/powerpc/Kconfig                     |   1 -
 arch/riscv/Kconfig                       |   1 -
 arch/s390/Kconfig                        |   1 -
 arch/sh/Kconfig                          |   1 +
 arch/sh/include/asm/pgalloc.h            |   6 +-
 arch/sh/mm/pgtable.c                     |  20 +++++
 arch/sparc/Kconfig                       |   4 +-
 arch/sparc/include/asm/pgalloc_32.h      |   7 +-
 arch/sparc/include/asm/pgalloc_64.h      |   8 --
 arch/sparc/include/asm/tlb_64.h          |   2 -
 arch/sparc/lib/bitext.c                  |  14 ++--
 arch/sparc/mm/srmmu.c                    |  32 ++++++--
 arch/um/Kconfig                          |   1 -
 arch/x86/Kconfig                         |   1 -
 arch/xtensa/include/asm/tlb.h            |   2 +-
 include/asm-generic/tlb.h                |  66 +++--------------
 mm/Kconfig                               |   2 +-
 mm/gup.c                                 |   5 +-
 mm/khugepaged.c                          |  32 +++++++-
 mm/mmu_gather.c                          |  30 ++------
 mm/pgtable-generic.c                     |  15 +++-
 35 files changed, 223 insertions(+), 192 deletions(-)
---
base-commit: 88297631d4d42f6004cb39c0ba3da7d2d10a616f
change-id: 20260831-rcu-pagetable-freeing-84b6be830e20

Best regards,
-- 
Lorenzo Stoakes (ARM) <ljs@kernel.org>

On Tue, 22 Sep 2026 16:35:31 +0100 "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:

> The majority of architectures in the kernel defer page table freeing until
> an RCU grace period has elapsed, this series converts all remaining
> architectures to do so too and eliminates CONFIG_MMU_GATHER_RCU_TABLE_FREE
> altogether.
> 
> This is important because it enables safe lockless page table walking under
> RCU alone.
> 
> Doing so allows for reduced lock contention, avoids lock ordering concerns
> and enables fast, efficient and correct page table walking as a result.
> 
> Additionally it removes a bunch of code and architecture-specific behaviour
> which is always a beneficial thing to do.
> 
> There has been much recent work on this:

Thanks, I've updated mm.git's mm-unstable branch to this version.  Plus
one -fix for [01/12].

> v4:
> * Updated the 1st patch to allocate a new page table on PTE deposit rather
>   than deposit a page table that might currently be being walked by an
>   RCU-only page table walker, as per David.

Here's how v4 altered mm.git:


 mm/huge_memory.c |    2 +-
 mm/khugepaged.c  |   34 ++++++++++++++++++++++++++++++++--
 2 files changed, 33 insertions(+), 3 deletions(-)

--- a/mm/huge_memory.c~b
+++ a/mm/huge_memory.c
@@ -2478,7 +2478,7 @@ static inline void zap_deposited_table(s
 	pgtable_t pgtable;
 
 	pgtable = pgtable_trans_huge_withdraw(mm, pmd);
-	pte_free_defer(mm, pgtable);
+	pte_free(mm, pgtable);
 	mm_dec_nr_ptes(mm);
 }
 
--- a/mm/khugepaged.c~b
+++ a/mm/khugepaged.c
@@ -1278,6 +1278,23 @@ static enum scan_result alloc_charge_fol
 	return SCAN_SUCCEED;
 }
 
+static pgtable_t alloc_deposit_pte(struct mm_struct *mm)
+{
+	/*
+	 * khugepaged is run from a kernel thread, so need to manually set the
+	 * correct memcg so the allocation gets charged correctly.
+	 */
+	struct mem_cgroup *memcg = get_mem_cgroup_from_mm(mm);
+	struct mem_cgroup *old_memcg = set_active_memcg(memcg);
+	pgtable_t pgtable;
+
+	pgtable = pte_alloc_one(mm);
+
+	set_active_memcg(old_memcg);
+	mem_cgroup_put(memcg);
+	return pgtable;
+}
+
 /*
  * collapse_huge_page() expects the mmap_lock to be unlocked before entering and
  * will always return with the lock unlocked, to avoid holding the mmap_lock
@@ -1293,7 +1310,7 @@ static enum scan_result collapse_huge_pa
 	LIST_HEAD(compound_pagelist);
 	pmd_t *pmd, _pmd;
 	pte_t *pte = NULL;
-	pgtable_t pgtable;
+	pgtable_t pgtable = NULL;
 	struct folio *folio;
 	spinlock_t *pmd_ptl, *pte_ptl;
 	enum scan_result result = SCAN_FAIL;
@@ -1310,6 +1327,14 @@ static enum scan_result collapse_huge_pa
 		goto out_nolock;
 	}
 
+	if (is_pmd_order(order)) {
+		pgtable = alloc_deposit_pte(mm);
+		if (!pgtable) {
+			result = SCAN_ALLOC_HUGE_PAGE_FAIL;
+			goto out_nolock;
+		}
+	}
+
 	mmap_read_lock(mm);
 	result = hugepage_vma_revalidate(mm, pmd_addr, /*expect_anon=*/ true,
 					 &vma, cc, order);
@@ -1433,8 +1458,8 @@ static enum scan_result collapse_huge_pa
 	spin_lock(pmd_ptl);
 	VM_WARN_ON_ONCE(!pmd_none(*pmd));
 	if (is_pmd_order(order)) {
-		pgtable = pmd_pgtable(_pmd);
 		pgtable_trans_huge_deposit(mm, pmd, pgtable);
+		pgtable = NULL;
 		map_anon_folio_pmd_nopf(folio, pmd, vma, pmd_addr);
 	} else {
 		/*
@@ -1453,6 +1478,9 @@ static enum scan_result collapse_huge_pa
 	}
 	spin_unlock(pmd_ptl);
 
+	if (is_pmd_order(order))
+		pte_free_defer(mm, pmd_pgtable(_pmd));
+
 	folio = NULL;
 
 	result = SCAN_SUCCEED;
@@ -1463,6 +1491,8 @@ out_up_write:
 		anon_vma_unlock_write(vma->anon_vma);
 	mmap_write_unlock(mm);
 out_nolock:
+	if (pgtable)
+		pte_free(mm, pgtable);
 	if (folio)
 		folio_put(folio);
 	trace_mm_collapse_huge_page(mm, result == SCAN_SUCCEED, result, order);
_

On Tue, Sep 22, 2026 at 04:35:31PM +0100, Lorenzo Stoakes (ARM) wrote:
> m68k-motorola required the biggest change - since RCU page table freeing
> uses call_rcu(), this means page table freeing can arise from softirq
> context.
> 
> This was fixed with an IRQ-safe spin lock used in both get_pointer_table()
> and free_pointer_table().

You don't need to use an irq-safe spinlock for softirqs.  It does work,
but it's overkill since it disables hardirqs.  If you use spin_lock_bh(),
only softirqs are prevented from running (and it's safe to call
spin_lock_bh() when in softirq context, just like it's safe to call
spin_lock_irqsave() in hardirq or softirq context).

On Tue, Sep 22, 2026 at 05:42:10PM +0100, Matthew Wilcox wrote:
> On Tue, Sep 22, 2026 at 04:35:31PM +0100, Lorenzo Stoakes (ARM) wrote:
> > m68k-motorola required the biggest change - since RCU page table freeing
> > uses call_rcu(), this means page table freeing can arise from softirq
> > context.
> >
> > This was fixed with an IRQ-safe spin lock used in both get_pointer_table()
> > and free_pointer_table().
>
> You don't need to use an irq-safe spinlock for softirqs.  It does work,
> but it's overkill since it disables hardirqs.  If you use spin_lock_bh(),
> only softirqs are prevented from running (and it's safe to call
> spin_lock_bh() when in softirq context, just like it's safe to call
> spin_lock_irqsave() in hardirq or softirq context).

Right yup, I know _bh() is fine for softirq, I think this was being overly
cautious (for sparc32 you do actually need irq saving).

But this is m68k :) functionally there's really not that much difference, and
it's over very few instrucitons so the delta here is likely to be functionally
little to nothing.

If I need to respin again I'll fix it up!

--
Cheers, Lorenzo

On Tue, 22 Sep 2026 16:35:31 +0100 "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:

> The majority of architectures in the kernel defer page table freeing until
> an RCU grace period has elapsed, this series converts all remaining
> architectures to do so too and eliminates CONFIG_MMU_GATHER_RCU_TABLE_FREE
> altogether.
> 
> This is important because it enables safe lockless page table walking under
> RCU alone.

Do we have reason to believe that anyone is seeing any effects from
their arch's failure to rcu-free the page tables?

This sounds like a rather long-standing wart, yes?

The patchset is thinly reviewed and mm.git is bursting at the seams
again.  I'll play wait-and-see on this series.  Feel free to cluebat me
if that's a bad call.

On 9/23/26 01:00, Andrew Morton wrote:
> On Tue, 22 Sep 2026 16:35:31 +0100 "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
> 
>> The majority of architectures in the kernel defer page table freeing until
>> an RCU grace period has elapsed, this series converts all remaining
>> architectures to do so too and eliminates CONFIG_MMU_GATHER_RCU_TABLE_FREE
>> altogether.
>>
>> This is important because it enables safe lockless page table walking under
>> RCU alone.
> 
> Do we have reason to believe that anyone is seeing any effects from
> their arch's failure to rcu-free the page tables?
> 
> This sounds like a rather long-standing wart, yes?
> 
> The patchset is thinly reviewed and mm.git is bursting at the seams
> again.  I'll play wait-and-see on this series.
Do we want to nudge arch maintainers to review?

-- 
Cheers,

David

On Wed, Sep 23, 2026 at 10:45:33AM +0200, David Hildenbrand (Arm) wrote:
> On 9/23/26 01:00, Andrew Morton wrote:
> > On Tue, 22 Sep 2026 16:35:31 +0100 "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
> >
> >> The majority of architectures in the kernel defer page table freeing until
> >> an RCU grace period has elapsed, this series converts all remaining
> >> architectures to do so too and eliminates CONFIG_MMU_GATHER_RCU_TABLE_FREE
> >> altogether.
> >>
> >> This is important because it enables safe lockless page table walking under
> >> RCU alone.
> >
> > Do we have reason to believe that anyone is seeing any effects from
> > their arch's failure to rcu-free the page tables?
> >
> > This sounds like a rather long-standing wart, yes?
> >
> > The patchset is thinly reviewed and mm.git is bursting at the seams
> > again.  I'll play wait-and-see on this series.
> Do we want to nudge arch maintainers to review?

(Just to note that I replied separately, 'thinly reviewed' is incorrect, it's
been in -next for weeks and the whole thing was reviewed by Kiryl.)

The only places where that would be useful is m68k motorola, sparc32.

But in any case it has been heavily tested including on every single arch
listed with stress testing performed (I think I cover that in the cover
letter).

The changes are not controversial so I don't think that's a blocker, but
it'd be nice?

>
> --
> Cheers,
>
> David

--
Cheers, Lorenzo

On 9/23/26 11:04, Lorenzo Stoakes (ARM) wrote:
> On Wed, Sep 23, 2026 at 10:45:33AM +0200, David Hildenbrand (Arm) wrote:
>> On 9/23/26 01:00, Andrew Morton wrote:
>>>
>>>
>>> Do we have reason to believe that anyone is seeing any effects from
>>> their arch's failure to rcu-free the page tables?
>>>
>>> This sounds like a rather long-standing wart, yes?
>>>
>>> The patchset is thinly reviewed and mm.git is bursting at the seams
>>> again.  I'll play wait-and-see on this series.
>> Do we want to nudge arch maintainers to review?
> 
> (Just to note that I replied separately, 'thinly reviewed' is incorrect, it's
> been in -next for weeks and the whole thing was reviewed by Kiryl.)

Ack.

> 
> The only places where that would be useful is m68k motorola, sparc32.
> 
> But in any case it has been heavily tested including on every single arch
> listed with stress testing performed (I think I cover that in the cover
> letter).
> 
> The changes are not controversial so I don't think that's a blocker, but
> it'd be nice?

I doubt we'll ever get sparc32 reviews :)

I'd definitely appreciate some review on the arch bits from arch maintainers,
but if they don't reply within the next weeks I wouldn't wait on that.

-- 
Cheers,

David

On 9/23/26 11:15, David Hildenbrand (Arm) wrote:
> On 9/23/26 11:04, Lorenzo Stoakes (ARM) wrote:
>> On Wed, Sep 23, 2026 at 10:45:33AM +0200, David Hildenbrand (Arm) wrote:
>>> On 9/23/26 01:00, Andrew Morton wrote:
>>>>
>>>>
>>>> Do we have reason to believe that anyone is seeing any effects from
>>>> their arch's failure to rcu-free the page tables?
>>>>
>>>> This sounds like a rather long-standing wart, yes?
>>>>
>>>> The patchset is thinly reviewed and mm.git is bursting at the seams
>>>> again.  I'll play wait-and-see on this series.
>>> Do we want to nudge arch maintainers to review?
>> 
>> (Just to note that I replied separately, 'thinly reviewed' is incorrect, it's
>> been in -next for weeks and the whole thing was reviewed by Kiryl.)
> 
> Ack.
> 
>> 
>> The only places where that would be useful is m68k motorola, sparc32.
>> 
>> But in any case it has been heavily tested including on every single arch
>> listed with stress testing performed (I think I cover that in the cover
>> letter).
>> 
>> The changes are not controversial so I don't think that's a blocker, but
>> it'd be nice?
> 
> I doubt we'll ever get sparc32 reviews :)
> 
> I'd definitely appreciate some review on the arch bits from arch maintainers,
> but if they don't reply within the next weeks I wouldn't wait on that.

Indeed, for minor arches like this the lack of review (it would be a whole
cycle by the merge window) shouldn't be a blocker for important tree-wide
progress.

On Wed, Sep 23, 2026 at 11:39:27AM +0200, Vlastimil Babka (SUSE) wrote:
> On 9/23/26 11:15, David Hildenbrand (Arm) wrote:
> > On 9/23/26 11:04, Lorenzo Stoakes (ARM) wrote:
> >> On Wed, Sep 23, 2026 at 10:45:33AM +0200, David Hildenbrand (Arm) wrote:
> >>> On 9/23/26 01:00, Andrew Morton wrote:
> >>>>
> >>>>
> >>>> Do we have reason to believe that anyone is seeing any effects from
> >>>> their arch's failure to rcu-free the page tables?
> >>>>
> >>>> This sounds like a rather long-standing wart, yes?
> >>>>
> >>>> The patchset is thinly reviewed and mm.git is bursting at the seams
> >>>> again.  I'll play wait-and-see on this series.
> >>> Do we want to nudge arch maintainers to review?
> >>
> >> (Just to note that I replied separately, 'thinly reviewed' is incorrect, it's
> >> been in -next for weeks and the whole thing was reviewed by Kiryl.)
> >
> > Ack.
> >
> >>
> >> The only places where that would be useful is m68k motorola, sparc32.
> >>
> >> But in any case it has been heavily tested including on every single arch
> >> listed with stress testing performed (I think I cover that in the cover
> >> letter).
> >>
> >> The changes are not controversial so I don't think that's a blocker, but
> >> it'd be nice?
> >
> > I doubt we'll ever get sparc32 reviews :)
> >
> > I'd definitely appreciate some review on the arch bits from arch maintainers,
> > but if they don't reply within the next weeks I wouldn't wait on that.
>
> Indeed, for minor arches like this the lack of review (it would be a whole
> cycle by the merge window) shouldn't be a blocker for important tree-wide
> progress.

Thanks appreciated!

Greg from m68k has had a look so seems we have movement there anyway! :)

--
Cheers, Lorenzo

On Tue, Sep 22, 2026 at 04:00:21PM -0700, Andrew Morton wrote:
> On Tue, 22 Sep 2026 16:35:31 +0100 "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:
>
> > The majority of architectures in the kernel defer page table freeing until
> > an RCU grace period has elapsed, this series converts all remaining
> > architectures to do so too and eliminates CONFIG_MMU_GATHER_RCU_TABLE_FREE
> > altogether.
> >
> > This is important because it enables safe lockless page table walking under
> > RCU alone.
>
> Do we have reason to believe that anyone is seeing any effects from
> their arch's failure to rcu-free the page tables?

We have reason to believe that it completely blocks other work like
scalable CoW :)

>
> This sounds like a rather long-standing wart, yes?

Not really, if you read the cover letter you can see the history of people
working on this, this is the final piece of the puzzle and despite the
rather muted reception this change is a big deal (TM).

>
> The patchset is thinly reviewed and mm.git is bursting at the seams
> again.  I'll play wait-and-see on this series.  Feel free to cluebat me
> if that's a bad call.

Err, Kiryl reviewed the entire series, I sent it in -rc1 of this cycle, and
it's been in -next forever?

Lance is reviewing now, presumably maybe David will review based on the
fact I updated on his feedback to _expand_ some functionality here.

So I'd argue this is contender for one of the top priority series for this
cycle, actually! [and is CRITICAL for my scalable CoW work, easily the most
important this cycle]

--
Cheers, Lorenzo

On Wed, 23 Sep 2026 08:04:25 +0100 "Lorenzo Stoakes (ARM)" <ljs@kernel.org> wrote:

> Err, Kiryl reviewed the entire series, I sent it in -rc1 of this cycle, and
> it's been in -next forever?

I'd failed to notice that v3 of this series was in mm.git, oops. 
Thanks for cluebatting.