On Tue, Dec 31, 2024 at 10:52:14AM +0000, Catalin Marinas wrote:
Hi Sasha, On Sun, Dec 29, 2024 at 08:46:21PM -0500, Sasha Levin wrote:commit 6b17ecf6de3064c79db2e53eca71e31c1a4da62e Author: Yunfeng Ye <yeyunfeng@xxxxxxxxxx> Date: Thu Dec 9 09:42:25 2021 +0800 arm64: mm: Rename asid2idx() to ctxid2asid() [ Upstream commit a3a5b763410c7bceacf41a52071134d9dc26202a ] The commit 0c8ea531b774 ("arm64: mm: Allocate ASIDs in pairs") introduce the asid2idx and idx2asid macro, but these macros are not really useful after the commit f88f42f853a8 ("arm64: context: Free up kernel ASIDs if KPTI is not in use"). The code "(asid & ~ASID_MASK)" can be instead by a macro, which is the same code with asid2idx(). So rename it to ctxid2asid() for a better understanding. Also we add asid2ctxid() macro, the contextid can be generated based on the asid and generation through this macro. Signed-off-by: Yunfeng Ye <yeyunfeng@xxxxxxxxxx> Reviewed-by: Kefeng Wang <wangkefeng.wang@xxxxxxxxxx> Link: https://lore.kernel.org/r/c31516eb-6d15-94e0-421c-305fc010ea79@xxxxxxxxxx Signed-off-by: Catalin Marinas <catalin.marinas@xxxxxxx> Stable-dep-of: c0900d15d31c ("arm64: Ensure bits ASID[15:8] are masked out when the kernel uses 8-bit ASIDs") Signed-off-by: Sasha Levin <sashal@xxxxxxxxxx> diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c index cd72576ae2b7..bbc2708fe928 100644 --- a/arch/arm64/mm/context.c +++ b/arch/arm64/mm/context.c @@ -35,8 +35,8 @@ static unsigned long *pinned_asid_map; #define ASID_FIRST_VERSION (1UL << asid_bits) #define NUM_USER_ASIDS ASID_FIRST_VERSION -#define asid2idx(asid) ((asid) & ~ASID_MASK) -#define idx2asid(idx) asid2idx(idx) +#define ctxid2asid(asid) ((asid) & ~ASID_MASK) +#define asid2ctxid(asid, genid) ((asid) | (genid))Is this patch needed only to ensure that commit c0900d15d31c ("arm64: Ensure bits ASID[15:8] are masked out when the kernel uses 8-bit ASIDs") applies cleanly? There's no functional dependency between them, just
Yes.
adjacent lines being changed by the two patches. Up to you if you prefer to cherry-pick another patch, it is harmless. Otherwise I'm happy to send backports for commit c0900d15d31c separately.
Even without a functional need, taking this dependency means that future commits in this area of code will continue to apply cleanly, and we'll diverge less from upstream. If taking this commit is harmless, then I'd rather have it and not a custom backport. -- Thanks, Sasha
