From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 6C58041B347 for ; Thu, 11 Jun 2026 15:37:12 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=217.140.110.172 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781192235; cv=none; b=WN/DLM9hCUUSepD5fm0ayn9ThjWZ5vYhjwGaiVt3k0Zws6/A97rkSgkuPjYpZvCFXDXPxxsFjU4eTnj6p6jDpQEaD15iRilCab5QiLfYhEGNx7FtmCxDEXBR5mlqcOP7vuXoFVzCWAls/R1wZS1yo6j/N9D4oTKu9Caho5shVw8= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1781192235; c=relaxed/simple; bh=rC/rAaBXV2GWXrpXt20/IdeSrbUuel7YWt1xLJbAR2o=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=DTfBurTzgf8TWrlJGUAUfr3mtc7RsTl3V4SX+fFWxRR9Iw7cBjZJ/zBg6n1PXnpGK3YfO72W95ggVobhlz6iOU6eJB+kqJ49q7tSGDh7gO5w7L02MlGVBOuKrOGJZmLwsIMMSk0xeeOCxqsrVYPK7Af8/PnYIKu5l9Dhaauowzs= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com; spf=pass smtp.mailfrom=arm.com; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b=JkqlpOPy; arc=none smtp.client-ip=217.140.110.172 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=arm.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=arm.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=arm.com header.i=@arm.com header.b="JkqlpOPy" Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id E168E25E2; Thu, 11 Jun 2026 08:37:06 -0700 (PDT) Received: from arm.com (usa-sjc-mx-foss1.foss.arm.com [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id CB8003FB90; Thu, 11 Jun 2026 08:37:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=arm.com; s=foss; t=1781192231; bh=rC/rAaBXV2GWXrpXt20/IdeSrbUuel7YWt1xLJbAR2o=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=JkqlpOPyTjeEMsaxUcBoGInfqHsuGFDsvG8vDkGT1ee11I71JtUQ3UvnNV0ISoC+H Rc8PzN3Zg2Ge2S7IKXzS0BI84YEb3c2ZcJOSWo72cNJsNBorxaEnMZ9ba2pp33jWXr LFLsmA4JBlYyziVBRP5k7zzDqRnofVtuBczSf1ww= Date: Thu, 11 Jun 2026 16:37:07 +0100 From: Catalin Marinas To: sk@gentwo.org Cc: linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, Will Deacon , Ryan Roberts , Andrew Morton , David Hildenbrand , Anshuman Khandual , Mike Rapoport , Dev Jain , Kevin Brodsky , Marc Zyngier , Oliver Upton , cl@gentwo.org, Sayali Kulkarni Subject: Re: [PATCH 2/2] arm64: tlbflush: Reset active_cpu on ASID rollover Message-ID: References: <20260609213615.2788698-1-sk@gentwo.org> <20260609213615.2788698-3-sk@gentwo.org> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20260609213615.2788698-3-sk@gentwo.org> On Tue, Jun 09, 2026 at 02:34:33PM -0700, sk@gentwo.org wrote: > From: Sayali Kulkarni > > Once active_cpu flips to ACTIVE_CPU_MULTIPLE, it never resets, even if > the process settles back to one CPU. Reset it to ACTIVE_CPU_NONE when > a new ASID is assigned after rollover, since flush_context() already > issued a global TLB flush at that point meaning no stale TLB entries > exist on any CPU. > > This gives processes a fresh chance at the local-only flush fast path > after each ASID generation rollover. flush_context() does not invalidate any TLBs, just marks the in a bitmap which CPUs need to flush, locally, on the next context switch. Check Sashiko's comments, it has some good points (you can ignore the comments on the first patch as we no longer rely on DVM for SVA. https://sashiko.dev/#/patchset/20260609213615.2788698-1-sk@gentwo.org > Signed-off-by: Sayali Kulkarni > --- > arch/arm64/mm/context.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c > index f34ed78393e0..0c92cc8fb4cd 100644 > --- a/arch/arm64/mm/context.c > +++ b/arch/arm64/mm/context.c > @@ -250,6 +250,7 @@ void check_and_switch_context(struct mm_struct *mm) > if (!asid_gen_match(asid)) { > asid = new_context(mm); > atomic64_set(&mm->context.id, asid); > + WRITE_ONCE(mm->context.active_cpu, ACTIVE_CPU_NONE); > } This breaks the case where you have another thread of the current process running on a different CPU. new_context(mm) will reuse the current ASID, just bump the generation, so setting active_cpu to ACTIVE_CPU_NONE is incorrect. A better place for this would be in new_context() after the "set_asid" label. > if (cpumask_test_and_clear_cpu(cpu, &tlb_flush_pending)) > @@ -321,6 +322,7 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm) > */ > asid = new_context(mm); > atomic64_set(&mm->context.id, asid); > + WRITE_ONCE(mm->context.active_cpu, ACTIVE_CPU_NONE); > } And it would cover this path as well (not that this function is used currently). -- Catalin