From nobody Mon Feb 9 16:33:03 2026 Received: from out28-101.mail.aliyun.com (out28-101.mail.aliyun.com [115.124.28.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 75E8742EECD for ; Tue, 20 Jan 2026 13:44:52 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.28.101 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768916696; cv=none; b=aG3rybEfFScKXiKjSZqWAJOCZgqa7IhrtvXUfdzftiKuyZmy1NQJ4Gjhs0/tGPymteZylJkgRNCsFFRBVg5+HV/CXRlS/Q0mpdjvsG7OjuXGpk0zFHkjSH+F+Dv8cpuSfWTX5mEa981nlTUwWedgCPedUGsIQ9XHspQWS5OoXpI= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768916696; c=relaxed/simple; bh=CxyRwCPxxyu3o24KbAOPA9JfEXyFEkeAlRxchIv4KNc=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=qjxdLwhChvNQ2QSVQBor+xASOu8JkUnVLEJZxNEHxpjNjecL39+x+TIU23il6wTi1kXnH4TM+rooq+FLrQOrzZoGIXrTDG2yd9FQphZT4onfOktMt9rIE3tKOsglRQV6gxbbLOnpxYO8RWQDs/gPHBgCZ2O6dCefRe4BLeHxBpU= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=antgroup.com; spf=pass smtp.mailfrom=antgroup.com; dkim=pass (1024-bit key) header.d=antgroup.com header.i=@antgroup.com header.b=OV4afaVH; arc=none smtp.client-ip=115.124.28.101 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=antgroup.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=antgroup.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=antgroup.com header.i=@antgroup.com header.b="OV4afaVH" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1768916685; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=FKhnB7NICtp/K/S4al/MVVRR3r1cRodJi5Sxt/Y0o/8=; b=OV4afaVHQU9lsnm7kAwJvnxA1t/0XDjG88PpC01FPrdfMlLWrRdFrHcGGorugRCMCJ8ggVy7FAur2gRfpG8qQyfF0IK1fwhxk1wIrUk/OY5rfUJ/5mzU3mVWWKvco0ViRHptFm2np3ChtMakAI4eIVWqGGUAdUCsU8fDy/n+h3E= Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gBI8bVU_1768916684 cluster:ay29) by smtp.aliyun-inc.com; Tue, 20 Jan 2026 21:44:44 +0800 From: Hou Wenlong To: linux-kernel@vger.kernel.org Cc: Hou Wenlong , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" , Rik van Riel Subject: [PATCH v2 4/4] x86/mm: Reset global ASID space when ASID rollover Date: Tue, 20 Jan 2026 21:44:30 +0800 Message-Id: <9dcd1fbbee53485fa1787f8f86ea879f526d3654.1768900340.git.houwenlong.hwl@antgroup.com> X-Mailer: git-send-email 2.31.1 In-Reply-To: References: Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" The global ASID allocation always searches for free ASIDs starting from the last allocated ASID and resets the ASID space when the last allocated ASID reaches the edge of the available ASID space. However, this approach fails in scenarios where the maximum ASID is allocated first and a smaller ASID is freed later. In such cases, the 'last_global_asid' may never reach the edge of the available ASID space, leading to allocation failures even when global ASIDs are available. For example, if all ASIDs are allocated in the first round and then a smaller ASID is freed, the ASID space can be reset because 'last_global_asid' equals 'MAX_ASID_AVAILABLE - 1'. The smaller ASID can then be allocated, and 'last_global_asid' is updated accordingly. However, when this smaller ASID is freed again, the allocation will fail since 'last_global_asid' no longer equals 'MAX_ASID_AVAILABLE - 1', preventing the ASID space from being reset. To address this issue, the global ASID space should be reset based on ASID rollover rather than depending on the value of 'last_global_asid'. Fixes: d504d1247e36 ("x86/mm: Add global ASID allocation helper functions") Signed-off-by: Hou Wenlong Reviewed-by: Rik van Riel --- arch/x86/mm/tlb.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index a7dbf784efd9..0f98b78a48cc 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -316,16 +316,18 @@ static void reset_global_asid_space(void) static u16 allocate_global_asid(void) { u16 asid; + bool reset =3D false; =20 lockdep_assert_held(&global_asid_lock); =20 - /* The previous allocation hit the edge of available address space */ - if (last_global_asid >=3D MAX_ASID_AVAILABLE - 1) - reset_global_asid_space(); - +restart: asid =3D find_next_zero_bit(global_asid_used, MAX_ASID_AVAILABLE, last_gl= obal_asid); - if (asid >=3D MAX_ASID_AVAILABLE) { + if (!reset) { + reset_global_asid_space(); + reset =3D true; + goto restart; + } /* This should never happen. */ VM_WARN_ONCE(1, "Unable to allocate global ASID despite %d available\n", global_asid_available); --=20 2.31.1