From: Magnus Lindholm <linmag7@gmail.com>
To: richard.henderson@linaro.org, mattst88@gmail.com,
linux-kernel@vger.kernel.org, linux-alpha@vger.kernel.org
Cc: glaubitz@physik.fu-berlin.de, mcree@orcon.net.nz,
ink@unseen.parts, macro@orcam.me.uk,
Magnus Lindholm <linmag7@gmail.com>
Subject: [PATCH 1/6] alpha: run check_mmu_context() from finish_arch_post_lock_switch()
Date: Sun, 9 Aug 2026 10:49:33 +0200 [thread overview]
Message-ID: <20260809085208.3262799-2-linmag7@gmail.com> (raw)
In-Reply-To: <20260809085208.3262799-1-linmag7@gmail.com>
check_mmu_context() clears asn_lock and acts on need_new_asn, but it runs
only as the tail of switch_to(), after alpha_switch_to() returns. A newly
forked task never gets there: its first context switch resumes at
ret_from_fork, which goes to schedule_tail() and then to user space rather
than returning to the code following alpha_switch_to(). A new kernel
thread reaches schedule_tail() the same way, through
ret_from_kernel_thread().
asn_lock is left set on that CPU, so the forked task runs user space with
it set and interrupts enabled. A TLB shootdown IPI arriving in that window
takes the deferred path, and the need_new_asn handshake meant to cover that
never runs.
finish_task_switch() calls finish_arch_post_lock_switch() with preemption
disabled, on the CPU that ran switch_mm(), so hooking check_mmu_context()
there completes the deferred-ASN bookkeeping for both. Running it when
switch_to() has already done the work is harmless: check_mmu_context()
clears need_new_asn as it goes.
The same hook is also called from kthread_use_mm() and
sched_force_init_mm(), outside the scheduler's preemption-disabled switch
tail. check_mmu_context() acts on per-CPU state, so it can only complete
this bookkeeping while still on the CPU that ran switch_mm(). Testing
preemptible() expresses that condition directly rather than naming callers:
where those paths leave preemption enabled the CPU may already have changed
and nothing is done, and where preemption is disabled across the switch, or
not configured at all, no migration is possible and running it is correct.
Signed-off-by: Magnus Lindholm <linmag7@gmail.com>
---
arch/alpha/include/asm/mmu_context.h | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/alpha/include/asm/mmu_context.h b/arch/alpha/include/asm/mmu_context.h
index eee8fe836a59..f7afc64ca8dd 100644
--- a/arch/alpha/include/asm/mmu_context.h
+++ b/arch/alpha/include/asm/mmu_context.h
@@ -181,6 +181,34 @@ do { \
#define check_mmu_context() do { } while(0)
#endif
+/*
+ * check_mmu_context() clears asn_lock and acts on need_new_asn, but it runs
+ * only as the tail of switch_to(), which a newly forked task never reaches:
+ * it resumes at ret_from_fork instead. asn_lock is left set and the task
+ * goes on to run user space with it set and interrupts enabled, so a
+ * shootdown IPI arriving in that window takes the deferred path and the
+ * need_new_asn handshake meant to cover it never runs.
+ *
+ * finish_task_switch() calls this hook with preemption disabled on the CPU
+ * that ran switch_mm(), which covers that case. Running it when switch_to()
+ * has already done the work is harmless: check_mmu_context() clears
+ * need_new_asn as it goes.
+ *
+ * kthread_use_mm() and sched_force_init_mm() also call this hook, outside
+ * the scheduler's preemption-disabled switch tail. check_mmu_context() acts
+ * on per-CPU state, so it can only complete this bookkeeping while still on
+ * the CPU that ran switch_mm(); preemptible() tests that directly. Where
+ * those paths leave preemption enabled the CPU may already have changed and
+ * nothing is done; where preemption is disabled across the switch, or not
+ * configured at all, no migration is possible and running it is correct.
+ */
+#define finish_arch_post_lock_switch finish_arch_post_lock_switch
+static inline void finish_arch_post_lock_switch(void)
+{
+ if (!preemptible())
+ check_mmu_context();
+}
+
__EXTERN_INLINE void
ev5_activate_mm(struct mm_struct *prev_mm, struct mm_struct *next_mm)
{
--
2.53.0
next prev parent reply other threads:[~2026-08-09 8:55 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-09 8:49 [PATCH 0/6] alpha: fix stale TLB translations breaking copy-on-write and writeback Magnus Lindholm
2026-08-09 8:49 ` Magnus Lindholm [this message]
2026-08-10 2:37 ` [PATCH 1/6] alpha: run check_mmu_context() from finish_arch_post_lock_switch() Matt Turner
2026-08-10 2:40 ` Matt Turner
2026-08-10 6:15 ` Magnus Lindholm
2026-08-09 8:49 ` [PATCH 2/6] alpha: only use a targeted tbi() when the target mm is really current Magnus Lindholm
2026-08-09 8:49 ` [PATCH 3/6] alpha: fix the local TLB invalidate in flush_tlb_page() Magnus Lindholm
2026-08-10 2:43 ` Matt Turner
2026-08-10 6:26 ` Magnus Lindholm
2026-08-09 8:49 ` [PATCH 4/6] alpha: only use a targeted tbi() when the target mm is really current (UP) Magnus Lindholm
2026-08-10 2:45 ` Matt Turner
2026-08-10 6:42 ` Magnus Lindholm
2026-08-09 8:49 ` [PATCH 5/6] alpha: invalidate the local context in flush_tlb_mm() Magnus Lindholm
2026-08-09 8:49 ` [PATCH 6/6] alpha: invalidate the local context in flush_icache_user_page() Magnus Lindholm
2026-08-10 3:03 ` Matt Turner
2026-08-10 6:11 ` Magnus Lindholm
2026-08-10 2:35 ` [PATCH 0/6] alpha: fix stale TLB translations breaking copy-on-write and writeback Matt Turner
2026-08-10 7:24 ` Magnus Lindholm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260809085208.3262799-2-linmag7@gmail.com \
--to=linmag7@gmail.com \
--cc=glaubitz@physik.fu-berlin.de \
--cc=ink@unseen.parts \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=macro@orcam.me.uk \
--cc=mattst88@gmail.com \
--cc=mcree@orcon.net.nz \
--cc=richard.henderson@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox