Re: [PATCH v2 0/7] alpha: fix stale TLB translations breaking copy-on-write and writeback

[Matt Turner <mattst88@gmail.com>]

On Mon, Aug 10, 2026 at 09:34:51PM +0200, Magnus Lindholm wrote:
>   mkclean4.c covers patches 3 and 5 (needs root), and fails on both SMP and
>   UP. A single thread writes a small MAP_SHARED file while background
>   writeback cleans it, and the file is then compared against the mapping;
>   every round loses data.

I wrote something along those lines and could not get it to fail on EV7,
on v7.3-rc1 without the series, with and without CONFIG_COMPACTION, on
both an SMP-enabled and a CONFIG_SMP=n kernel. Only one CPU was online
throughout, so none of this exercises the multi-CPU paths. Writeback was
running underneath: 850 to 1700 pages written back per run.

The path is reached, though. With counters in flush_tlb_page() on the
unpatched kernel:

    ftp: cur=77824 lazy=324 other=466
    ftp lazy: loaded asn=0 mm asn=79 pid=12 comm=kworker/u4:0
    ftp lazy: loaded asn=0 mm asn=138 pid=12 comm=kworker/u4:0

so the flusher does issue the targeted tbi() with ASN 0 loaded against an
mm whose ASN is 79, a few hundred times per run, exactly as you describe.
The writer keeps faulting afterwards and the page keeps being redirtied,
so nothing is lost.

The reading that fits is that the EV7 PALcode invalidates by VA without
matching the ASN, which would make this unobservable here and observable
on your EV68. If you have a way to distinguish that from the console I am
happy to run it. Either way the test is wrong by the architecture, so the
patches stand on their own.

One thing that confused me for a while, and may be worth a line in the
changelog: since dd5712f3379c ("alpha: fix user-space corruption during
memory compaction") alpha overrides ptep_clear_flush() to call
migrate_flush_tlb_page(), and that override is inside #ifdef
CONFIG_COMPACTION in asm/pgtable.h. With COMPACTION=y, folio_mkclean()
never reaches flush_tlb_page() at all, so mkclean4 should pass there
whether or not this series is applied. I take it your failing runs are the
COMPACTION=n ones. That also raises the question of why the correct
flushing in ptep_clear_flush() is conditional on COMPACTION in the first
place, but that is not this series.

On patch 1: alpha selects ARCH_NO_PREEMPT, so unless something drags in
PREEMPT_COUNT (DEBUG_ATOMIC_SLEEP, say) preemptible() is 0 and the hook
always runs, including after kthread_use_mm(). The changelog says the hook
does nothing there and that the later patches rely on asn_lock staying
set, which is then only true for PREEMPT_COUNT=y builds. Since patches 2
and 3 lean on that window, it would help to say so.

On the changes since v1: dropping the check_mmu_context() call from
switch_to() means the bookkeeping now runs after finish_lock_switch() has
re-enabled interrupts, rather than with them still off. I convinced myself
that window is harmless, since the CPU is in kernel code throughout and
the case that matters sets need_new_asn, but "no functional change from
v1" undersells it.

For what it is worth on EV7 with one CPU, with the series applied: no
regressions in a gdb breakpoint exerciser, a fork/COW check, or the
writeback test above, on either kernel.