From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-ed1-f44.google.com (mail-ed1-f44.google.com [209.85.208.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 211FC3B5E15 for ; Sun, 9 Aug 2026 08:55:30 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.208.44 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265731; cv=none; b=fENyKYAKUo7KKv6jBatJUtxAS26esFIZQIgTANyTEe1RL91TKkuIaWMedpCwkZdSKmnrD2sr0mbr8rFCYexs4PrP6nmc7U3oPcI8jWWCKABYy0gWGv+mqmBmpwebxPr/zhI3H4/9wNPaLBPgYKhqAF2dHzQw6c81CV+0wINHIwk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1786265731; c=relaxed/simple; bh=YaFajEc++EZydpQQWr/F6blWM6a4+OFkGgPACbvd+fE=; h=From:To:Cc:Subject:Date:Message-ID:In-Reply-To:References: MIME-Version; b=f5gcV7i1NjzCRbEYC4ackY5Dfz3aUL4i3EDytCnLfbIIx/UajaVa0YIKrWU3FDM7EKLp1bUhMssd6eGAPyj+QCniP6Pp0Pl3wGdv1fNE3kqUHaBsRIGwv+ngfO7dtI7+cKEzBNc8X2MsJH0gMN/i2vS66mUOWC5Yy5benpopBNc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=nsxcW32o; arc=none smtp.client-ip=209.85.208.44 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="nsxcW32o" Received: by mail-ed1-f44.google.com with SMTP id 4fb4d7f45d1cf-6a0a4aa99bdso957838a12.1 for ; Sun, 09 Aug 2026 01:55:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1786265728; x=1786870528; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to:content-type; bh=tIXrb9knWmO6iHNuE9igc2E6FtJyIXy1wsmdNsvGwYc=; b=nsxcW32oKPHK9ROnGGURXxVr3B0EQ/33BJRcHRl8mCSzymgDaOToTP806WwnO2ASnJ SmP7747l7gSC4KmBjUnvdSHYTXUc/pXJI4zt68rBzCeZulZ51wIQm4XFlR1SGWnnhNIu j+grzKjWkAQRb3XZr2GgrT5XAOVj70Nfe+l0G4Lg4SOT9XUMa5pBSfpVi/UXmBfrGo+J Wq2Ek5eCNgWSmw9vTlNca9NfbLsgBNaYwCjXNmdEFMOisHloxNzxDfMwC9cep1+rl/kf dBY1zDdcB9soToX/QPcVGok5TkD8uJKk3jHw7tesXxJzPixR6i2UsveSBZ9ThTy/kCXd xvcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1786265728; x=1786870528; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:date:subject:cc:to:from:x-gm-gg:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to:content-type; bh=tIXrb9knWmO6iHNuE9igc2E6FtJyIXy1wsmdNsvGwYc=; b=R7N0DlmpQScfTnkdEfZ/HBJdeW86uv28Z+fhTA0aHmlHzhXCvxAFbufD9kD9ihUCof QNbviat9sI3GR/qDMe3vY0yE2epftHLvxeT74OUlIon03fy5z3hgk+pz1DSGVJ7U3iif N9TOWtDI97wNsoKiUiU41yTSjy+OHQagnd+UQ0fqXrLLr3pA5FKdus/CBEGhuNLYdgSS GkXlumnQ2gC4/Cl8yj8P1aB4hgdW/qT0PKemgUYVFxn/e9JkPN6GQL+2z+n9DwaSB50h lZ+Hr/yrLrqyJC6MUN9PxkW/3i0eGf5n+NG6kdFGszKIEe0oC9Sk5lju89iromqJEPjK Wxww== X-Forwarded-Encrypted: i=1; AHgh+RqWfukwUKkfd6PzcCqfRQAWqfvdIDcPeXw8icSgMVUt+UIlM2a4MNe3/hbnVHP13Hisz/fz1PZRtCfmCRA=@vger.kernel.org X-Gm-Message-State: AOJu0YyNEfc4BCfIIUHI7al+bt2VdqwlGMVW+C/lFgmRGGc6pHe3vnbp 2xP173UyVprek03NBSWrEbHgJqKaKPwvtUhQMpzsfM+SxYne91VCw3Ai X-Gm-Gg: AR+sD13EWiaTM/H/x25hhKaeX5tmfwc7Ug5HW5o2UWQnSiYaC0g/kY673VGwC1YmOg4 YHi2scR9OCZ3Nd7ccrJHUcW69SRoZTbzGo9Jcn3aVyzyPFf9vtXAKoHItI2hd0kRq1JEsAVyQgK p/t6LcNgXqc2PlCobWUdFk10xvsgm/AxyrWID7/0YVfp2xm0+l1bIMIYhFlVpl5XncYBwtTlepQ IFbMbdPK1/voYJemWty4aQt7xxgXcrqzWFHfXzMvIUHW6+TAE5z55wi8bSMzvhfcq39mGb44x6B gVCmFL7qOR4ey/JEh4Xs0QMoftfbapl4IFZyDyYPM7vpUhpLNABdAB6SnSc6BFY9HWj3Hv4bg/X JSvK2UrcjkS2FdS6wKiCdp3arEvSaeYrkjdNKM0ZCqvQj6UbJh2vvv4FfFERirXBKM+xW2bFtZj DVLA8YqKBsCrOck76ErR0BT7N4mseQEy+zDfQrSpLHh+pDAqWPiOfeP/7n/DEzEshNaITTCtrYG l9649nFPQHN3zOv+ZbJq0PnhwT6ceA= X-Received: by 2002:a05:6402:11d0:b0:6a1:b515:c3c1 with SMTP id 4fb4d7f45d1cf-6a1b515c6a2mr9877208a12.4.1786265728373; Sun, 09 Aug 2026 01:55:28 -0700 (PDT) Received: from buildhost.darklands.se ([2001:9b1:ff:d701:51eb:176f:63d9:53f8]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-6a1f630a4afsm1606681a12.3.2026.08.09.01.55.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 09 Aug 2026 01:55:27 -0700 (PDT) From: Magnus Lindholm 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 Subject: [PATCH 1/6] alpha: run check_mmu_context() from finish_arch_post_lock_switch() Date: Sun, 9 Aug 2026 10:49:33 +0200 Message-ID: <20260809085208.3262799-2-linmag7@gmail.com> X-Mailer: git-send-email 2.53.0 In-Reply-To: <20260809085208.3262799-1-linmag7@gmail.com> References: <20260809085208.3262799-1-linmag7@gmail.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit 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 --- 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