From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from out28-123.mail.aliyun.com (out28-123.mail.aliyun.com [115.124.28.123]) (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 BF4BE3816EF for ; Tue, 20 Jan 2026 13:44:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=115.124.28.123 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768916690; cv=none; b=NXtSw+Gg1zsIqse8Ryt3AUryyUuMACSN0jEyT5HSZ9WBSge0e9v/78FqxQ+Iy+uzAcwbhbZ6bAgrcHT/rzOrgDKmXM/q1bfn5FRWPTiaPVvKcnjE+R5NA+zN7YyBlsB56cCKEKERQpsy4edANQ0MEcVaNTvrGEFHU2xPsTtiahs= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1768916690; c=relaxed/simple; bh=XX+JtuyQLBkOD3rNv1MCy2p+NqVSXuq7HYdHFqnwNDw=; h=From:To:Cc:Subject:Date:Message-Id:MIME-Version; b=cn7SfGF28xPnskaXJTWpchpDvok9E6h6f07azcz3I6VHhg6AKPLI6tuOlyPFZa6uH9X9MGx9TaczACtA7kKIIegz/lX78yTiyeBhzxtYxXDsSf4ZWFI0SO6hrycdAnqEO3oCXnFRuC3ps9g3VuIsvBxH6Xh9+h1f8dmZKI+FyxI= 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=bj1C/32T; arc=none smtp.client-ip=115.124.28.123 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="bj1C/32T" DKIM-Signature:v=1; a=rsa-sha256; c=relaxed/relaxed; d=antgroup.com; s=default; t=1768916677; h=From:To:Subject:Date:Message-Id:MIME-Version; bh=JSqecjATBkmHg3XUpCzYnoFPgRSE/tGX72WB8+8aNBY=; b=bj1C/32TtmVH1wB7r1PUOkCYW1WMOZYxlNodcWWhTFZdJJlV8cRQ2Djouz9u2yvKv+TZOtOPTg+EAKhlU8Xw/X9TzXNqq44QTK7HYO5EYdeB9ZyfoeVMU4EKUz+LB5sUn8z0lLqPPo/VC1ZNVeJwQ6gzjKzdupzNsWnKzbOLez8= Received: from localhost(mailfrom:houwenlong.hwl@antgroup.com fp:SMTPD_---.gBHvy4a_1768916676 cluster:ay29) by smtp.aliyun-inc.com; Tue, 20 Jan 2026 21:44:37 +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 0/4] x86/mm: Some fixes about global ASID allocation Date: Tue, 20 Jan 2026 21:44:26 +0800 Message-Id: X-Mailer: git-send-email 2.31.1 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit During the backporting of the global ASID allocation, I found some issues with the ASID range size calculations, and I'm not sure if I misread them. Firstly, it's just a mathematical calculation. When we describe a range [a,b] as a closed interval, the size of the range should be 'b - a + 1'. As noted in the comment, the range for global ASIDs is [TLB_NR_DYN_SIZE, MAX_ASID_AVAILABLE-1], and the size of the bitmap is also defined as 'MAX_ASID_AVAILABL', Therefore, the size of the range should be 'MAX_ASID_AVAILABLE - TLB_NR_DYN_SIZE'. However, 'global_asid_available' is assigned the value of 'MAX_ASID_AVAILABLE - TLB_NR_DYN_SIZE - 1', which means one ASID will never be allocated. The macro 'MAX_ASID_AVAILABLE', as I understand it, is used to represent the maximum valid ASID. Thus the available ASID range described in the comments is [0,MAX_ASID_AVAILABLE], which is a close interval too. So the acutal size of the range is 'MAX_ASID_AVAILABLE + 1'. But it is incorrectly used as the size of the bitmap in global ASID allocation, leading to the maximum ASID being excluded from global ASID allocation. As referenced in [1], there is an issue: when a smaller ASID is freed and last_global_asid is not equal to 'MAX_ASID_AVAILABLE-1', the allocation will fail because the ASID space cannot be reset. This can be fixed by resetting the ASID space when an ASID rollover occurs, regardless of the value of 'last_global_asid'. Additionally, I found that when PTI is off but 'CONFIG_MITIGATION_PAGE_TABLE_ISOLATION' is enabled (which should be true for broadcast TLB-capable hardware), only half of the ASID space is available because 'MAX_ASID_AVAILABLE' is defined as 2046. I have made some changes to expand the entire ASID space for global ASID allocation when PTI is off, but I haven't covered this in this patchset. I am considering whether we can align ASID and PCID to make the code clearer as Rik said in [0]. Note, I have only conducted some basic tests (running the 4096 tlb_flush2_threads tests to trigger ASID rollover) on the AMD platform. v1: https://lore.kernel.org/lkml/cover.1743250122.git.houwenlong.hwl@antgroup.com [0]: https://lore.kernel.org/lkml/df4f0ce855b7acd6fc9777457b89359e075a5cbb.camel@surriel.com v1 -> v2: - Add a new patch to fix the allocation failure. - Rewrite the commit message and add Reviwed-by tag. Hou Wenlong (4): x86/mm: Correct the actual size of available global ASID range x86/mm: Fix wrong judgement in allocate_global_asid() x86/mm: Correct the actual size of ASID range x86/mm: Reset global ASID space when ASID rollover arch/x86/mm/tlb.c | 25 +++++++++++++------------ 1 file changed, 13 insertions(+), 12 deletions(-) base-commit: d613f96096e48b3646217f006bcccc6ff973c428 -- 2.31.1