Re: [PATCH v2] mm/shmem, swap: fix race of truncate and swap entry split

From: Andrew Morton

Date: Sun Jan 18 2026 - 22:45:07 EST


On Mon, 19 Jan 2026 10:17:50 +0800 Kairui Song <ryncsn@xxxxxxxxx> wrote:

> >
> > What tree was this prepared against?
> >
> > Both Linus mainline and mm.git have
> >
> > : static long shmem_free_swap(struct address_space *mapping,
> > : pgoff_t index, void *radswap)
> > : {
> > : int order = xa_get_order(&mapping->i_pages, index);
> > : void *old;
> > :
> > : old = xa_cmpxchg_irq(&mapping->i_pages, index, radswap, NULL, 0);
> > : if (old != radswap)
> > : return 0;
> > : free_swap_and_cache_nr(radix_to_swp_entry(radswap), 1 << order);
> > :
> > : return 1 << order;
> > : }
> >
> > but that free_swap_and_cache_nr() call is absent from your tree.
>
> Oh, I tested and sent this patch based on mm-unstable, because the bug
> was found while I was testing swap table series. This is a 2 year old
> existing bug though. Swapoff during high system pressure is not a very
> common thing, and maybe mTHP for shmem is currently not very commonly
> used either? So maybe that's why no one found this issue.
>
> free_swap_and_cache_nr is renamed to swap_put_entries_direct in
> mm-unstable, it's irrelevant to this fix or bug. The rename change was
> made here:
> https://lore.kernel.org/linux-mm/20251220-swap-table-p2-v5-14-8862a265a033@xxxxxxxxxxx/
>
> Should I resend this patch base on the mainline and rebase that
> series? Or should we merge this in mm-unstable first then I can
> send seperate fixes for stable?

I think a clean fix against Linus mainline, please. Then let's take a
look at what's needed to repair any later problems.