Received: by 2002:a05:6a10:17d3:0:0:0:0 with SMTP id hz19csp21308pxb; Wed, 14 Apr 2021 08:31:42 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwGicNG4q1nTgrBLAf2zuXrFOdKqBqtup6hxBxg34zbCsIHs1KlCrIr5ndw+f+8jrtt8gu4 X-Received: by 2002:a05:6402:3092:: with SMTP id de18mr40631291edb.96.1618414301947; Wed, 14 Apr 2021 08:31:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1618414301; cv=none; d=google.com; s=arc-20160816; b=I3nWmw9eh4In8dZNajYDQ5fib7GGlas7kQYJh0zy+Ww9HG0f+tSa+dVKLmN0ax1092 6fZb8Q+dXO3BrFI4SeD5Qf69X0q5ir9h+3mTaW/ncCa5GGBVRNY5AC8jyuUHvVHmmP2l ODA9WeJs1ZbbGL5Z5WodIeKq8QoLd4RmO8849bpKEwqpha4FpcNW9ZZ+KGfiTKQKQTrD 4bDG5MRAPg5phLg+N09gUMAHnqtu1e8x/15FDA52CXb0Y5+nDd2y4THnR7dM1Q923y4T NOgCL8vHxYXJH9tf5ZHcZkLT4S6QjXTHVTKIUntHMHuQWGAwU3lhfTkFEk4Rd8XHP0Mj q83g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:references:in-reply-to:message-id :date:subject:cc:to:from; bh=ih+OJLWOl+FYbi6jXZMyfDz7G9VdYKXjRagfws6UGQE=; b=xI9KUimbxD2jZ5JVReh/Gy075SWKSYMjU6WAgyxnn4ftWEDbgVLkDgjW//KqQ/MURl 48vv35pei8eVOnHL+i4xZQbpwrevYVgBL34Rg4rGu0oxjDF7GS7pkVWZ82Orejy+RTcq FHPrUWudbKpEjIrE3hh4UQttMx+3X0ZDm6ylnV5vvPO2AYgHqH1N/uzd6AKUIfqECy2i GdReIM+ZntlmIe08Y9CDz1dBQVR8lkiabuzXq1PdHLFwhLvhWb25O3VUqLcTc267R8T9 p7MF+yDKePOekQ4DFyIYrwneNLbDTk/96P6mtvOlUI1xXZ2mGRWqTdJitJR36GPFVelf uDWg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id gw24si12521070ejb.508.2021.04.14.08.31.06; Wed, 14 Apr 2021 08:31:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=huawei.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S234031AbhDNLZj (ORCPT + 99 others); Wed, 14 Apr 2021 07:25:39 -0400 Received: from szxga04-in.huawei.com ([45.249.212.190]:16586 "EHLO szxga04-in.huawei.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1350475AbhDNLZS (ORCPT ); Wed, 14 Apr 2021 07:25:18 -0400 Received: from DGGEMS414-HUB.china.huawei.com (unknown [172.30.72.59]) by szxga04-in.huawei.com (SkyGuard) with ESMTP id 4FL0SY0Cxlz18Hlm; Wed, 14 Apr 2021 19:22:37 +0800 (CST) Received: from S00345302A-PC.china.huawei.com (10.47.82.32) by DGGEMS414-HUB.china.huawei.com (10.3.19.214) with Microsoft SMTP Server id 14.3.498.0; Wed, 14 Apr 2021 19:24:43 +0800 From: Shameer Kolothum To: , , CC: , , , , , , , , Subject: [PATCH v4 05/16] arm64/mm: Remove dependency on MM in new_context Date: Wed, 14 Apr 2021 12:23:01 +0100 Message-ID: <20210414112312.13704-6-shameerali.kolothum.thodi@huawei.com> X-Mailer: git-send-email 2.12.0.windows.1 In-Reply-To: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com> References: <20210414112312.13704-1-shameerali.kolothum.thodi@huawei.com> MIME-Version: 1.0 Content-Type: text/plain X-Originating-IP: [10.47.82.32] X-CFilter-Loop: Reflected Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Julien Grall The function new_context will be part of a generic ASID allocator. At the moment, the MM structure is currently used to fetch the ASID and pinned refcount. To remove the dependency on MM, it is possible to just pass a pointer to the current ASID and pinned refcount. Also please note that 'pinned' may be NULL if the user doesn't require the pinned asid support. Signed-off-by: Julien Grall Signed-off-by: Shameer Kolothum --- v3-->v4: Changes related to Pinned ASID refcount. --- arch/arm64/mm/context.c | 11 ++++++----- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/arch/arm64/mm/context.c b/arch/arm64/mm/context.c index 139ebc161acb..628304e0d3b1 100644 --- a/arch/arm64/mm/context.c +++ b/arch/arm64/mm/context.c @@ -165,9 +165,10 @@ static bool check_update_reserved_asid(struct asid_info *info, u64 asid, return hit; } -static u64 new_context(struct asid_info *info, struct mm_struct *mm) +static u64 new_context(struct asid_info *info, atomic64_t *pasid, + refcount_t *pinned) { - u64 asid = atomic64_read(&mm->context.id); + u64 asid = atomic64_read(pasid); u64 generation = atomic64_read(&info->generation); if (asid != 0) { @@ -185,7 +186,7 @@ static u64 new_context(struct asid_info *info, struct mm_struct *mm) * takes priority, because even if it is also pinned, we need to * update the generation into the reserved_asids. */ - if (refcount_read(&mm->context.pinned)) + if (pinned && refcount_read(pinned)) return newasid; /* @@ -257,7 +258,7 @@ void check_and_switch_context(struct mm_struct *mm) /* Check that our ASID belongs to the current generation. */ asid = atomic64_read(&mm->context.id); if (!asid_gen_match(asid, info)) { - asid = new_context(info, mm); + asid = new_context(info, &mm->context.id, &mm->context.pinned); atomic64_set(&mm->context.id, asid); } @@ -306,7 +307,7 @@ unsigned long arm64_mm_context_get(struct mm_struct *mm) * We went through one or more rollover since that ASID was * used. Ensure that it is still valid, or generate a new one. */ - asid = new_context(info, mm); + asid = new_context(info, &mm->context.id, &mm->context.pinned); atomic64_set(&mm->context.id, asid); } -- 2.17.1