Received: by 2002:ac0:a594:0:0:0:0:0 with SMTP id m20-v6csp889567imm; Wed, 23 May 2018 07:07:30 -0700 (PDT) X-Google-Smtp-Source: AB8JxZpHwOGUlMJTiyTWLCKWsW8peg4qp9nbkaBD7d+mqN/8aQGCdvk6rxj6DMuOEc4nDXf/wtwP X-Received: by 2002:a17:902:524:: with SMTP id 33-v6mr3165413plf.25.1527084449987; Wed, 23 May 2018 07:07:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1527084449; cv=none; d=google.com; s=arc-20160816; b=UdH4gSxEwbfHS7JGR6ryQy/soix8a3FdCTlFl1nXT2DiJdqbz4gopJCSqHf19H+7qM xX7i4+tEm9K2gF3rh8xBYES2OgQztJ6Lp6fakQvQmaKa2kaby3m3dkKhpwhCs7WGelek 1Uorz2vuioB8Q7hlScHBq0wZdpQJCmSkTgMKe79eYkiFNt663I7nsqbgm0Y9XUYxSEru 3vLT2Ds1Mls1M/tP7b1atbWGP71lM3flBKLafk4ZMoG+w8KWFJ0uELIzvISFDc7+1gag //F64/cmkPJlqTlI54SbYIGCrCQkOiH5NzzzEaCc96aR41xvIrPzaaticG9go40x/xMz 9E/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:arc-authentication-results; bh=7LGEzOyv8omjrN4QBvl0GsviKf5Za/pHt5TGmSrp8cs=; b=L8pq4EoXdoCCJ49qyYdqKP5fULqTQ6PnIq8Ffu6k1u5rR/3sZNKHgUlVvQSkBvA1/y wyz3yBNlvx289x1KctJBrGQn8NCfH67/D73O09qAtaOoY6NVME225v8h2b9RHaQXwPhr 2ahoPg6KE6NM2dVxasaGzO4vW/frp2oJYcEABb9rSciNEq0iA5G/ucsNhM6cvOsMNnoo EzDWLFORO3loQ/CPUKI4yevLcyxSkMT2G5KOO9jwbvYJYW+OiMb0kLdyWa3P1QcoaA5t enu+MnCBJKBn99Lag/wO5HPYPSDhF5xzqEIBU6YYqV2gDonPMyJ9vxgoCe3Zz64Ik1FN 3khQ== ARC-Authentication-Results: i=1; mx.google.com; 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 v66-v6si14929826pgv.344.2018.05.23.07.06.44; Wed, 23 May 2018 07:07:29 -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; 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 S933135AbeEWOBc (ORCPT + 99 others); Wed, 23 May 2018 10:01:32 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:55860 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933104AbeEWOBa (ORCPT ); Wed, 23 May 2018 10:01:30 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 793F280D; Wed, 23 May 2018 07:01:30 -0700 (PDT) Received: from edgewater-inn.cambridge.arm.com (usa-sjc-imap-foss1.foss.arm.com [10.72.51.249]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id 497A23F557; Wed, 23 May 2018 07:01:30 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id 251FB1AE540A; Wed, 23 May 2018 15:01:58 +0100 (BST) Date: Wed, 23 May 2018 15:01:58 +0100 From: Will Deacon To: Chintan Pandya Cc: Arnd Bergmann , Mark Rutland , Ard Biesheuvel , Marc Zyngier , Andrew Morton , Thomas Gleixner , Ingo Molnar , "H. Peter Anvin" , Philip Elcan , James Morse , Kristina Martsenko , Toshi Kani , Dave Hansen , Vitaly Kuznetsov , Joerg Roedel , Greg Kroah-Hartman , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org Subject: Re: [PATCH v9 3/4] arm64: Implement page table free interfaces Message-ID: <20180523140157.GG26965@arm.com> References: <1525074094-25839-1-git-send-email-cpandya@codeaurora.org> <1525074094-25839-4-git-send-email-cpandya@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1525074094-25839-4-git-send-email-cpandya@codeaurora.org> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Chintan, [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?] 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) > + table = __va(pmd_val(*pmdp)); Can you avoid dereferencing *pmdp twice, and instead READ_ONCE into a local variable, please? (same for pud) > + 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) > + } > + 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. Will