Re: [PATCH 00/16] mm/shmem: various (urgent?) fixes

[Kairui Song]

On Mon, Oct 26, 2026 at 5:44 PM David Hildenbrand (Arm)
<david@xxxxxxxxxx> wrote:
>
> Hi,
>
> the fixing fun continues.
>
> This is a handful of fixes for shmem/tmpfs. I sneaked in a related
> hugetlb fix that stalled upstream.
>
> Some of the stuff is more urgent (patch #1, F_SEAL_EXEC, truncation
> hangs), others are less urgent but still rather unpleasant.
>
> The majority are fixes from Anthropic that I cleaned up or reworked.
> While doing that, I found a bunch of other issues and tried to fix them
> somewhat cleanly.
>
> In general, shmem + swap handling is a nightmare. shmem_undo_range() is
> such utter garbage it makes me want to cry. I mean, really, WTF did we
> end up creating there. Does any expert here have time to clean that up and
> make it *actually* maintainable.

I had a nightmare understanding what is going on there when I was
trying to fix a few swap related bug... :P, and hesitated to clean it
up... I think we will have a cleaner codebase on this part soon as
Baolin is working on this.

> The following things are still broken in shmem_undo_range():
>
> (1) Truncate/punch of a single page of a large swap-error marker
>
> We don't split. Consequently, read access afterwards will still fail
> instead of returning 0s.
>
> I have a fix to try to split (which can fail), but I don't consider it
> that urgent, really. So I'm not including it. Might send it later
> separately.
>
> Truncate/punch of a partial page can obviously never do the right thing,
> as we cannot poison parts of pages ...
>
> (2) Truncate/punch whole pages within part of a large swap entry
>
> We try to read the entry, but if we are out of memory that might fail.
> Consequently, we will not free up swap space and a re-read will not give
> us 0s but the previous content.
>
> AI proposed a nasty NOFAIL patch which has too many nasty side effects
> IMHO (allowing users to force-read pages and retain them afterwards even
> though memory.max would disallow it). This needs a proper thought. Likely,
> support for splitting large swap entries (and large folios in the
> swapcache, which I recall is under development  by Kairui). But splitting
> can fail ...

Right, will post something on that swap cache splitting part soon,
what I found tricky afterward is lazy reclaim of swap cache so I think
a bit further clean up of THP splitting is needed first for better
swap cache splitting.

For shmem side, we don't have to swap in at all when truncating
page-sized holes for large swap entry. There is nothing complex from
swap side, just lock the cluster, then put/free these sub-entries, and
everything is good. It has to do a swapin for shmem right now just to
make the shmem part easier to reuse the folio entry split code and
better synchronize, IIUC. Nothing is blocking this except that we
better cleanup for the large shmem entry splitting code too?

> (3) Truncate/punch of a part of a base-page swap entry
>
> We obviously have to read the page in, in order to 0-out the parts to
> discard. That might obviously fail.
>
> Maybe we should install swapin-error markers if swapping during
> truncate/punchhole fails, to at least tell user space on later access
> that something went wrong? We might affect unrelated data, outside the
> requested range, though. Anyhow, these are long standing issues and
> I don't consider them urgent.
>
> They need a proper solution.

This part is tricky though... perhaps swap side needs to provide some
helpers to trim sub-page sized content on the backend (not sure). If
that's too complex maybe limiting the trim window to just 1 page a
time won't be too ugly?