From nobody Mon Feb 9 15:06:57 2026 Received: from out28-74.mail.aliyun.com (out28-74.mail.aliyun.com [115.124.28.74]) (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 4AB513D2FF5 for ; Tue, 20 Jan 2026 13:50:06 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.28.74 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768917012; cv=none; b=jYjGvZZJWRWBEW7S9o0kd/4X+fUbbAMRiyozTorrMdj4C6Rxjt2UdHeQ3OK68iaYHNoq4mkIQoKqQEwL6TyjlIchBoWbxkao92XrRjGstFMNeZFnnjiAESufyQimqZbpk5q6+1pcYfkQNgt8SMPUcIixUmf9INsB+NJfFENIUM8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768917012; c=relaxed/simple; bh=vAuKNcn69oxFTnKZdEx4No3npPltdTqe4a+MeHE53xA=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=VWPOeSZ1yWJT2/Gu+KkuZ5X4oqZOuJrzj7+9EpVtzQiv1it6c2yRmalXWnIDB5ETNNVefOi259EHt7YBjy9DV8hN2OfU3BGEy2m/w8RLaQzNUbviDmPwU0M7J6uwr4kbdFgXEPbtB3mGoHFDuOJkgxqyXAtizg2N1/xv9gsku/g= 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=bBUfqjir; arc=none smtp.client-ip=115.124.28.74 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="bBUfqjir" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1768916997; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=8RCL6736AGQ0Au6J3vFGkQ2igwAm4ViOK4v9rQxGzSU=; b=bBUfqjirYzDUs0fPmuGAHmRSR9VTa9B0LKrz4kSfGvCiZUFjWugDhtKBh5W5OGRdMLSW1ezcovJqwtTw3k4qksoVTK0LyjOGAJrGpC3Q5ZJEn4gytKY/7Iq4ck4IoHMiSVSp5IM89hTC/H2UFXYUjk+mr2uXkB5imGClbUsUEjc= Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gBJQwxu_1768916678 cluster:ay29) by smtp.aliyun-inc.com; Tue, 20 Jan 2026 21:44:38 +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" Subject: [PATCH v2 1/4] x86/mm: Correct the actual size of available global ASID range Date: Tue, 20 Jan 2026 21:44:27 +0800 Message-Id: <30c6abf8d2a246cde256f943adaa7251ae09b2df.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" As noted in the comment, the available ASID range for global ASID allocation is '[TLB_NR_DYN_ASIDS, MAX_ASID_AVAILABLE-1]', which is a close interval. The size of bitmap is defined as 'MAX_ASID_AVAILABLE', so the actual available size should be '(MAX_ASID_AVAILABLE-1) - TLB_NR_DYN_ASIDS + 1'; otherwise, one ASID will leak. Signed-off-by: Hou Wenlong Reviewed-by: Rik van Riel --- arch/x86/mm/tlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index 621e09d049cb..42b025e2f825 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -286,7 +286,7 @@ static DEFINE_RAW_SPINLOCK(global_asid_lock); static u16 last_global_asid =3D MAX_ASID_AVAILABLE; static DECLARE_BITMAP(global_asid_used, MAX_ASID_AVAILABLE); static DECLARE_BITMAP(global_asid_freed, MAX_ASID_AVAILABLE); -static int global_asid_available =3D MAX_ASID_AVAILABLE - TLB_NR_DYN_ASIDS= - 1; +static int global_asid_available =3D MAX_ASID_AVAILABLE - TLB_NR_DYN_ASIDS; =20 /* * When the search for a free ASID in the global ASID space reaches --=20 2.31.1 From nobody Mon Feb 9 15:06:57 2026 Received: from out28-122.mail.aliyun.com (out28-122.mail.aliyun.com [115.124.28.122]) (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 4B77734A764 for ; Tue, 20 Jan 2026 13:44:48 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.28.122 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768916693; cv=none; b=kl9ZTjGjFYTUA10+mhYgQrnVNuCavzoQ/3L0k5mD/GAsUUhJI7AT0H/TO7N/84bAevWYnEmrSD7kFsFnHT8NfLT8dfLDhnrOCYJWGU+NWo/3mqWT65pS4qmkOkmHZT2cfy93PkAhC7KHwLyRikgE9V1PukRahtUa4v3EVNIlSQs= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768916693; c=relaxed/simple; bh=l5TCr6d0DBNUImXYllUM1CzphLMo9G7REtug++RTJy4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=g2sVepipZ8NO37wd4jvNIbQJ3F26YGLy4BVbq2i9415zJswX3byDVC6vfO95lWPuBJMU3fRVZrwXIidjn4GqqNLihKZpvzC2k6L3Uf0QplwiVX4QmvMqzH5MLKDhhxzAxX635x9U3lRfqj6Qm5KQxEeWno7HM62I1kpXseLFyOk= 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=hdCVSHZw; arc=none smtp.client-ip=115.124.28.122 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="hdCVSHZw" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1768916681; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=WJMpK15aVPs71VpaiKevDcKfNPdj8VTYSyZEWH/2LUo=; b=hdCVSHZwUfa08xb1j3UKo66ZKrBXXmv16Q+AVQi/vRWkL3a5oMe7Xb6enjMLHflDVSgIiP7bnrAkIF65UaPykZh7xIMATvllFbivCcrGhIk/4j/P/JZDEs45QiGZI37a49jtCc/E6qwFrlNgYEZRSZ61Gbv+sqg55FyRCCb6JWQ= Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gBJQx.0_1768916680 cluster:ay29) by smtp.aliyun-inc.com; Tue, 20 Jan 2026 21:44:40 +0800 From: Hou Wenlong To: linux-kernel@vger.kernel.org Cc: Hou Wenlong , Rik van Riel , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" Subject: [PATCH v2 2/4] x86/mm: Fix wrong judgement in allocate_global_asid() Date: Tue, 20 Jan 2026 21:44:28 +0800 Message-Id: <7351bac66842ba58a9da011ea2ad45fb26079638.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" In allocate_global_asid(), 'global_asid_available' cannot be zero, as it has already been checked in use_global_asid(). The wrong judgment could result in the invalid ASID 'MAX_ASID_AVAILABLE' being allocated, triggering the warning in kern_pcid(). Therefore, remove the check for 'global_asid_available', since when the allocation reaches 'MAX_ASID_AVAILABLE', it must return regardless of the value of 'global_asid_available'. Fixes: d504d1247e36 ("x86/mm: Add global ASID allocation helper functions") Reviewed-by: Rik van Riel Signed-off-by: Hou Wenlong --- arch/x86/mm/tlb.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index 42b025e2f825..a1e217a382d1 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -326,7 +326,7 @@ static u16 allocate_global_asid(void) =20 asid =3D find_next_zero_bit(global_asid_used, MAX_ASID_AVAILABLE, last_gl= obal_asid); =20 - if (asid >=3D MAX_ASID_AVAILABLE && !global_asid_available) { + if (asid >=3D MAX_ASID_AVAILABLE) { /* This should never happen. */ VM_WARN_ONCE(1, "Unable to allocate global ASID despite %d available\n", global_asid_available); --=20 2.31.1 From nobody Mon Feb 9 15:06:57 2026 Received: from out28-49.mail.aliyun.com (out28-49.mail.aliyun.com [115.124.28.49]) (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 05C7043CEE4 for ; Tue, 20 Jan 2026 14:00:19 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.28.49 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768917627; cv=none; b=F1KUFzObWZhJI0SdWyB5JejtBvNa1e65EqByI2z0BRWk7waFXfBfL0jhKGPgJ6TOJ3wuYOvWWtAjlxXLmpS8fAFY5aqSl+G8i0fTamP6oNl3jv7UAazeAtK9LgFF5Sbzy+mNykfU1Rnbpr8lvg1j7HhxMG3ckW8veGxmE15T7a8= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768917627; c=relaxed/simple; bh=qV7sFD7d2CwKszwpDUJ+ikOh03YHTFWwVwq9ObTPQu4=; h=From:To:Cc:Subject:Date:Message-Id:In-Reply-To:References: MIME-Version; b=NprBOBjXnlQd0eGZymEH5wfsFrOI5HGJB489H/AJmHifhUuY5oFI65fUQAtfNqd8BWr3tar+VwAQm542SuVzOtrW2cBkemDd6KAJm4OCljxTuC8DDFU6E2TEGHasBB3p4cmG9XuO5DEODvIEpwfrUjXzznpyoO/lNfuZR/NwoUg= 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=iI73HzZz; arc=none smtp.client-ip=115.124.28.49 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="iI73HzZz" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1768917617; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=sTkVCVZTjPf1c3AyREStwj7y7AWARz4AUrAqG2zGhTA=; b=iI73HzZz6NkLWL+pGAJNG06MeC4gmiN9lrMeRu56/KVaKcBv0dE1X44cIj73yzlTEZCIUYru9YOPnmLmgSvzPIIPaSxfZBq4EAnr5julMT9/fbJ7ptxnejgHBFV6C9oGJ/wdK4dVi5DNBATA36sHhtdXKfuGfMJa8fkIY77yTHU= Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gBJ4V-6_1768916682 cluster:ay29) by smtp.aliyun-inc.com; Tue, 20 Jan 2026 21:44:42 +0800 From: Hou Wenlong To: linux-kernel@vger.kernel.org Cc: Hou Wenlong , Rik van Riel , Dave Hansen , Andy Lutomirski , Peter Zijlstra , Thomas Gleixner , Ingo Molnar , Borislav Petkov , x86@kernel.org, "H. Peter Anvin" Subject: [PATCH v2 3/4] x86/mm: Correct the actual size of ASID range Date: Tue, 20 Jan 2026 21:44:29 +0800 Message-Id: <9feb4672b89ba928fe16cb43eb9602dd9392040f.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" As noted in the comment, 'MAX_ASID_AVAILABLE' represents the maximum valid ASID, i.e., the valid ASID range is '[0, MAX_ASID_AVAILABLE]'. Therefore, the actual size of the ASID range should be 'MAX_ASID_AVAILABLE + 1', as it is zero-based. However, global ASID allocation uses this value as the size of the bitmap, which results in the maximum ASID being excluded from global ASID allocation. To address this issue, redefine the 'MAX_ASID_AVAILABLE' as the size of ASID range. Reviewed-by: Rik van Riel Signed-off-by: Hou Wenlong --- arch/x86/mm/tlb.c | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/arch/x86/mm/tlb.c b/arch/x86/mm/tlb.c index a1e217a382d1..a7dbf784efd9 100644 --- a/arch/x86/mm/tlb.c +++ b/arch/x86/mm/tlb.c @@ -104,18 +104,17 @@ #define CR3_AVAIL_PCID_BITS (X86_CR3_PCID_BITS - PTI_CONSUMED_PCID_BITS) =20 /* - * ASIDs are zero-based: 0->MAX_AVAIL_ASID are valid. -1 below to account - * for them being zero-based. Another -1 is because PCID 0 is reserved for - * use by non-PCID-aware users. + * ASIDs are zero-based: 0->MAX_ASID_AVAILABLE-1 are valid. -1 is because + * PCID 0 is reserved for use by non-PCID-aware users. */ -#define MAX_ASID_AVAILABLE ((1 << CR3_AVAIL_PCID_BITS) - 2) +#define MAX_ASID_AVAILABLE ((1 << CR3_AVAIL_PCID_BITS) - 1) =20 /* * Given @asid, compute kPCID */ static inline u16 kern_pcid(u16 asid) { - VM_WARN_ON_ONCE(asid > MAX_ASID_AVAILABLE); + VM_WARN_ON_ONCE(asid >=3D MAX_ASID_AVAILABLE); =20 #ifdef CONFIG_MITIGATION_PAGE_TABLE_ISOLATION /* --=20 2.31.1 From nobody Mon Feb 9 15:06:57 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