Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3619994imm; Mon, 4 Jun 2018 06:44:18 -0700 (PDT) X-Google-Smtp-Source: ADUXVKKdy4TSx3Zdbz5DyRvS0FgYH2M7Gpqb2FJxAwo/1eBNH4Nlds5iXGWx9OwdRlYEeQJLF0NS X-Received: by 2002:a62:e8d:: with SMTP id 13-v6mr1288966pfo.63.1528119858921; Mon, 04 Jun 2018 06:44:18 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1528119858; cv=none; d=google.com; s=arc-20160816; b=nLOTvGGsvb0TQ4GVKz+OPcpVBUmdqcLfbnBT0Nm1ptqinoAIHXK+Yc18T323le+J5x +pCFHtMrX4WCgSfa2NiOs533XN0fg+B0CjaP9uwMrHxusLWQwtRT+RvpWWUg42pqQfgE 3skJKP9LSAzrOaxPK9WnLrv43R1VIloswSDI+bie6AgN0XF1HciJL9ZzzvkpmUxokhMX e55qeMEYl7pNBLRYFwHDf69pUUnUUzK38BAtjk/+IMzkdLMhNqUnItx30QYwX3XpFX8X 3tBwZp6cesjk0EshodEivUmAfOkXqBqt106ZWOcMrSf/pe5IgfZG897jejsfGuPdNwNL cQeA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dmarc-filter :dkim-signature:dkim-signature:arc-authentication-results; bh=DpiJnij5c2dTlwjWD6ybgXH/0mhErMCJ6LGKLXLsMCU=; b=QYi5iAXG4ZAchsPP1yrMHW2d2UZTXUa3hmVTTvhD5ryEE+VbQcJvCzTq9hg+A681pj 4GnQ8U556VZWZOj4mZ0ehpWZbBfOHfSY2S5dcGpRZlWRBzRS+L6tgJL9bUy7GJ4g5trZ hXpSnwpkQj9ZIR4oYqTr/XDmUfUjv2taoTrJGpphBMEp4uSDUKF5CzA9lWaUhl5eJlAB 0M6wdAEevAWR47BiJJLDX4JXrZgjIkBWrB36+Aknv5g8cpfe+UEiGJKJOOBbTxdTvGmp VnIEd8+12UtXsYF6UJZQPaHIrQG6fpC3HkWLDEpazULv4Y53bRba7p+XFEKz8Vq9mWAc Gb0Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=JkqqlCd3; dkim=pass header.i=@codeaurora.org header.s=default header.b=Efuz/FBP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b5-v6si47497774ple.417.2018.06.04.06.44.04; Mon, 04 Jun 2018 06:44:18 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=JkqqlCd3; dkim=pass header.i=@codeaurora.org header.s=default header.b=Efuz/FBP; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753228AbeFDNnZ (ORCPT + 99 others); Mon, 4 Jun 2018 09:43:25 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:49964 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752800AbeFDNnY (ORCPT ); Mon, 4 Jun 2018 09:43:24 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 6D99760224; Mon, 4 Jun 2018 13:43:23 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1528119803; bh=SdqnUoS4LSlaP0l9bgCUSZbzqOXlD9jhsRp5AmdjLhg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=JkqqlCd3UwIjydHlVBkYx2PgKlrl3UHH7zBMuv6pi8cKhR9dCy2QL2OjSXEiF/yW3 vVe8AGNZc8pJEJdK/f0UowzOl/k4G5UQxbO0bInHoxr7bAdXsFhj1X+gOyjUZkHbbo AraA1dG6oAsWFzYyjR++YfOjG0+F/UlShg/MIrQA= X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on pdx-caf-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=2.0 tests=ALL_TRUSTED,BAYES_00, DKIM_SIGNED,T_DKIM_INVALID autolearn=no autolearn_force=no version=3.4.0 Received: from [10.204.79.109] (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: cpandya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id DA90B6085C; Mon, 4 Jun 2018 13:43:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1528119801; bh=SdqnUoS4LSlaP0l9bgCUSZbzqOXlD9jhsRp5AmdjLhg=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Efuz/FBPTy66+KnU9G5JgiFzUD25om7N3CaweT+YQXWTfPIdhwoCyGyTs+MzI0iHB ZfXuIrxhjD68VDr+KK8lCTCMrIPRihMVTaC/eJul4q5Upn8SMDGggdkunL8SxWdSJt /8i+OvdsVgNZglaRLOHJT4gzZA9P4Jx54nW8xggY= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org DA90B6085C Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none (p=none dis=none) header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=none smtp.mailfrom=cpandya@codeaurora.org Subject: Re: [PATCH v12 4/5] arm64: Implement page table free interfaces To: Will Deacon Cc: catalin.marinas@arm.com, mark.rutland@arm.com, akpm@linux-foundation.org, toshi.kani@hpe.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org References: <1527856758-27169-1-git-send-email-cpandya@codeaurora.org> <1527856758-27169-5-git-send-email-cpandya@codeaurora.org> <20180604121328.GG9482@arm.com> From: Chintan Pandya Message-ID: <98ef3cd0-a9a1-d5b5-f1a6-c0ab8b15ec6a@codeaurora.org> Date: Mon, 4 Jun 2018 19:13:18 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180604121328.GG9482@arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/4/2018 5:43 PM, Will Deacon wrote: > On Fri, Jun 01, 2018 at 06:09:17PM +0530, Chintan Pandya wrote: >> Implement pud_free_pmd_page() and pmd_free_pte_page(). >> >> Implementation requires, >> 1) Clearing off the current pud/pmd entry >> 2) Invalidate TLB which could have previously >> valid but not stale entry >> 3) Freeing of the un-used next level page tables > > Please can you rewrite this describing the problem that you're solving, > rather than a brief summary of some requirements? Okay. I'll fix this in v13. > >> Signed-off-by: Chintan Pandya >> --- >> arch/arm64/mm/mmu.c | 38 ++++++++++++++++++++++++++++++++++---- >> 1 file changed, 34 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c >> index 8ae5d7a..6e7e16c 100644 >> --- a/arch/arm64/mm/mmu.c >> +++ b/arch/arm64/mm/mmu.c >> @@ -45,6 +45,7 @@ >> #include >> #include >> #include >> +#include >> >> #define NO_BLOCK_MAPPINGS BIT(0) >> #define NO_CONT_MAPPINGS BIT(1) >> @@ -977,12 +978,41 @@ int pmd_clear_huge(pmd_t *pmdp) >> return 1; >> } >> >> -int pud_free_pmd_page(pud_t *pud, unsigned long addr) >> +int pmd_free_pte_page(pmd_t *pmdp, unsigned long addr) >> { >> - return pud_none(*pud); >> + pte_t *table; >> + pmd_t pmd; >> + >> + pmd = READ_ONCE(*pmdp); >> + if (pmd_present(pmd)) { >> + table = pmd_page_vaddr(pmd); >> + pmd_clear(pmdp); >> + __flush_tlb_kernel_pgtable(addr); >> + pte_free_kernel(NULL, table); >> + } >> + return 1; >> } >> >> -int pmd_free_pte_page(pmd_t *pmd, unsigned long addr) >> +int pud_free_pmd_page(pud_t *pudp, unsigned long addr) >> { >> - return pmd_none(*pmd); >> + pmd_t *table; >> + pmd_t *entry; >> + pud_t pud; >> + unsigned long next, end; >> + >> + pud = READ_ONCE(*pudp); >> + if (pud_present(pud)) { > > Just some stylistic stuff, but please can you rewrite this as: > > if (!pud_present(pud) || VM_WARN_ON(!pud_table(pud))) > return 1; > > similarly for the pmd/pte code above. Okay. v13 will have this. > >> + table = pud_page_vaddr(pud); >> + entry = table; > > Could you rename entry -> pmdp, please? Sure. > >> + next = addr; >> + end = addr + PUD_SIZE; >> + do { >> + pmd_free_pte_page(entry, next); >> + } while (entry++, next += PMD_SIZE, next != end); >> + >> + pud_clear(pudp); >> + __flush_tlb_kernel_pgtable(addr); >> + pmd_free(NULL, table); >> + } >> + return 1; > > So with these patches, we only ever return 1 from these helpers. It looks > like the same is true for x86, so how about we make them void and move the > calls inside the conditionals in lib/ioremap.c? Obviously, this would be a > separate patch on the end. That sounds valid code churn to me. But since x86 discussion is not concluded yet, I would wait to share until that gets resolved. May be not in v13 but separate effort. Would that be okay to you ? > > Will > Chintan -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project