Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp1794298imm; Thu, 24 May 2018 00:40:16 -0700 (PDT) X-Google-Smtp-Source: AB8JxZoJRpnb1/CpqtQyKB/gIDqK2sOpqW7LWi592ryDxBU9s46CyaU7w4/AOJTm2W5ksimiyMgX X-Received: by 2002:a63:7344:: with SMTP id d4-v6mr4834156pgn.273.1527147615950; Thu, 24 May 2018 00:40:15 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527147615; cv=none; d=google.com; s=arc-20160816; b=TKJgSHHMGNyR0qQJpX4LLuhVVGEoBI/YkNaxZvBrpx2qFwOz4YHnSYcUTRRdWsRM2W Pryx9Wx9zYivqBc2OqW6S7x8DJu+TSR+KdnXSVCD3xUDmsCXC14e37rbe92WZLR+3145 R95TpKJaIT+w2yo3eZzi/D7qbQHWrfrj/NwjOtsyEqKHKGw7p/68sxHcU3ij1jDsFZ9R HFDRn9c+HcHoF7GN1KxQMkqLXdLpHbGlhiXjG4NCaxLJ/a1xedrb/yS5BSaGDE+zx7Ro I0xoXIIIxYfHaWfHEVEY94sockTzevzBdDIxH8bV9edWV0I+lw59V6WH6s5+nzNDxjJ+ YnPg== 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=GAO4vdqvJpGL6c/Ibqb95WrUM7Swp+IXw5EW9ngI4v0=; b=D94z21N6PVFdS7xF0dJxu+hvhEanZX9b6Tbi4k9Lzi9sbehYjlqe0pXYUn2kohs6pR 9XwRSZmXm1k/LFiBfqssowgXrfI/ngI553NiMcKXFUV/z0hzRyBH6jhixfzG33fC98ut VZFn/XTC2aMztHgb1SgwyhMELsEwXDoFWdSYx0sV6ltwZmbDpAQ7AZBlFe7TG7X6rWME 5kgxJaSyLJzNIQtcaW8BJmJDJrSU45bn3C2AsknTN2rpnEvguZkbwYXZiEmb19Bo86m0 RKrsPXIWsXzVaJJhsdwZE+lre3M/2HGFJPyGtLpE5Ufkmy6a0aCWtUm6nj7qykFv3tJc N+zw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=k8YzqoQ0; dkim=pass header.i=@codeaurora.org header.s=default header.b=kFl4t5RS; 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 r4-v6si16495642pgp.103.2018.05.24.00.40.01; Thu, 24 May 2018 00:40:15 -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=k8YzqoQ0; dkim=pass header.i=@codeaurora.org header.s=default header.b=kFl4t5RS; 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 S935742AbeEXHe3 (ORCPT + 99 others); Thu, 24 May 2018 03:34:29 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:33804 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S935498AbeEXHe1 (ORCPT ); Thu, 24 May 2018 03:34:27 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 5C59F60F94; Thu, 24 May 2018 07:34:26 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1527147267; bh=aLGxr0kJRxTpBePKeCqPIjM/IxvRcT1wRt57rkBj4/w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=k8YzqoQ0Zs0vSeCeGQJTokNKNuWy9gQgO1qGp3gopB0eFRvWPmHyHwlsolOivFy+H 6mFi5pw8cuPkI7PWBWYQ16P8vhWM7rkrnJTBiimBxnZfTpbe3kPeqJUg1yGASYS6Vj y8yRX29YtoI+UdZVVNh0PYX1NiIuiOlFCNTwfBnk= 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 8D52160618; Thu, 24 May 2018 07:34:17 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1527147265; bh=aLGxr0kJRxTpBePKeCqPIjM/IxvRcT1wRt57rkBj4/w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=kFl4t5RSvoV8ny+276GYDog/tlN9eTbXDqsRSJqAus4cLeC8W9i0Do5AXD9pRYxgJ Aq7mmvHiYj/gshjDkfXytXF2UwIMEBRG2uhp5QpZv+/9ciKY/7eArppSslvXWopdgs 9H4cJf6waLa7iprCND3SIiK08rRR2orLnCirj1Zc= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 8D52160618 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 v9 3/4] arm64: Implement page table free interfaces To: Will Deacon Cc: Mark Rutland , linux-arch@vger.kernel.org, Philip Elcan , Toshi Kani , Arnd Bergmann , Ard Biesheuvel , Marc Zyngier , Greg Kroah-Hartman , Joerg Roedel , Dave Hansen , linux-kernel@vger.kernel.org, Kristina Martsenko , Vitaly Kuznetsov , Ingo Molnar , James Morse , "H. Peter Anvin" , Andrew Morton , Thomas Gleixner , linux-arm-kernel@lists.infradead.org References: <1525074094-25839-1-git-send-email-cpandya@codeaurora.org> <1525074094-25839-4-git-send-email-cpandya@codeaurora.org> <20180523140157.GG26965@arm.com> From: Chintan Pandya Message-ID: <9a059bc1-07eb-031b-e561-7e1eaabbf980@codeaurora.org> Date: Thu, 24 May 2018 13:04:15 +0530 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0 MIME-Version: 1.0 In-Reply-To: <20180523140157.GG26965@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 5/23/2018 7:31 PM, Will Deacon wrote: > Hi Chintan, Hi Will, > > [as a side note: I'm confused on the status of this patch series, as part > of it was reposted separately by Toshi. Please can you work together?] I will share all 4 patches once again as v10 and take latest version of 1/4 as updated by Toshi. > > On Mon, Apr 30, 2018 at 01:11:33PM +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 >> >> Signed-off-by: Chintan Pandya >> --- >> arch/arm64/mm/mmu.c | 29 +++++++++++++++++++++++++---- >> 1 file changed, 25 insertions(+), 4 deletions(-) >> >> diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c >> index da98828..0f651db 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) >> @@ -973,12 +974,32 @@ 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); >> + pmd_t *table; >> + >> + if (pmd_present(READ_ONCE(*pmdp))) { > > Might also be worth checking pmd_table here, just in case. (same for pud) I had that check in v2 as below. if (pud_val(*pud) && !pud_huge(*pud)) But removed that in v3 as unmap should change this to NONE if it is not table. I still don't see the need of it. > >> + table = __va(pmd_val(*pmdp)); > > Can you avoid dereferencing *pmdp twice, and instead READ_ONCE into a local > variable, please? (same for pud) Okay. > >> + pmd_clear(pmdp); >> + __flush_tlb_kernel_pgtable(addr); >> + free_page((unsigned long) table); > > Shouldn't this be pte_free_kernel, to pair with pte_alloc_kernel which > was used to allocate the page in the first place? (similarly for pud) Okay. > >> + } >> + 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; >> + int i; >> + >> + if (pud_present(READ_ONCE(*pudp))) { >> + table = __va(pud_val(*pudp)); >> + for (i = 0; i < PTRS_PER_PMD; i++) >> + pmd_free_pte_page(&table[i], addr + (i * PMD_SIZE)); > > I think it would be cleaner to write this as a do { ... } while, for > consistency with the ioremap and vmalloc code. Okay. I'll raise v10 fixing above things. Thanks for the review. > > Will > > _______________________________________________ > linux-arm-kernel mailing list > linux-arm-kernel@lists.infradead.org > http://lists.infradead.org/mailman/listinfo/linux-arm-kernel > 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