Re: [PATCH 0/3] alpha: load the MMU context on a direct mm switch

[Matt Turner <mattst88@gmail.com>]

On Fri, Sep 04, 2026 at 06:23:28PM +0200, Magnus Lindholm wrote:
> Reproducing it. A KUnit test was written for patch 3; source can be made
> available on request. It uses kunit_attach_mm(), which calls
> kthread_use_mm(), and then compares the loaded context against current->mm:

I wrote a similar one and ran it on an ES47 (EV7), on v7.3-rc1 with
the v2 stale-TLB series applied, with and without this series. Only
one CPU was online, so patch 2's shortcut never had another CPU to
look at.

Without the series the ptbr check fails. With it the test passes
(3/3, including user accesses before and after sleeping), and so do
usercopy_kunit (4/4) and kunit_iov_iter (17/17). A fork/COW check
running under continuous compact_memory showed no corruption, and
fork throughput was unchanged.

One difference from what you saw: the stale ptbr here was not
swapper_pg_dir.

    Expected pcb->ptbr == mm_ptbr(current->mm), but
        pcb->ptbr == 44986 (0xafba)
        mm_ptbr(current->mm) == 42112 (0xa480)

swapper_pg_dir is PFN 0x800 on this kernel, so 0xafba is the page
table of whatever user process ran on that CPU last. The kthread then
reads and writes that process's memory at any address mapped in both,
and TLB fills made that way get tagged with the borrowed mm's ASN.
That is worse than a fault loop.

> Patches 2 and 3 have no Cc: stable: kthread_use_mm() is the only
> reachable caller on alpha through KUnit's kunit_attach_mm():

I don't think that holds. vhost still has a kthread worker mode
(vhost_run_work_kthread_list()) that calls kthread_use_mm().
VHOST_ENABLE_FORK_OWNER_CONTROL defaults to y, and userspace can pick
that mode with VHOST_SET_FORK_FROM_OWNER or fork_from_owner_default=0.
The USB gadget f_fs and gadgetfs AIO paths call it too, and dummy_hcd
works on any architecture. vdpa_sim is another. Given that the failure
is cross-process memory access, I'd add Cc: stable to 3, and to 2,
which fixes the missed shootdowns for the same borrowed mms.

Two notes on the patches themselves.

In patch 2, it would help to say in the commit message why keeping
stale slots is cheap: the IPI makes each remote CPU that isn't running
the mm clear its own slot in flush_tlb_other(), so a process that
migrated once pays one extra round of IPIs and then goes back to the
shortcut. That was the first question I had reading it, and the answer
is only implicit in the cover letter's fork numbers.

In patch 3, the next == current test is fine, but the comment could
name kthread_use_mm() and sched_force_init_mm() so the next person
knows why the scheduler never takes that branch.

For patch 3:

Tested-by: Matt Turner <mattst88@gmail.com>

Patches 1 and 2 only matter with more than one CPU, and with one
online neither the removed loop nor the new check has anything to
look at, so no tags on those until I can test on SMP.