Received: by 10.213.65.68 with SMTP id h4csp910895imn; Tue, 27 Mar 2018 11:02:35 -0700 (PDT) X-Google-Smtp-Source: AIpwx4/47bzDJ60O2PmF3ar6PyOjLO5d5gtjtIKtSgYB4/OD0cRBSfcrF2FGCzF4n62urBscefhi X-Received: by 2002:a17:902:b406:: with SMTP id x6-v6mr323155plr.232.1522173755111; Tue, 27 Mar 2018 11:02:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1522173755; cv=none; d=google.com; s=arc-20160816; b=tfWmTgG9W4d6uB9eqWOnj5ScKfqfKpgAhtH8cyWPuvaxXoOWN9KsXFPCMjRMoR5k3F sEF6HwZMiV5kNCdt7KiAg45buYYJqqVeQGrywwpAYVve8Qbf/L6ujrP5lmcBMWJ2Pfnh UnO7U5wmHx+6NAl8aKQnfVEmU9Gm3jlvTHvfPxHWzZHXBQjMRdt+Qf33WSkC2vRevTuw msB7372qECGXNVoMvE8b3m3iRMLlE5/3aqBEa9iVI8s472x2lIb71uwW1rlrvBx+s7FW Qb0PtITB6UrS9jw4/4BDE2lb9f6KiyBImmSPPDCzSLSCB5HDcitpOaKqry4sW8CWTBXX 5PZw== 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=2cQRaZj5JVDMmxUytvTdSflNCmKVcZrdwjIJmILAcdc=; b=tsWt4pYjbS2Uv8pX3SxqQtg2ariDTWe8ZkFO46M1uM8viiW0xdCXgovuZOmyi1xVHa honyQavAZezgruwvMv7zh12xvkxWfHviAwhIpYOm82bPDqMp0zFOWsAWWAFNFGy3ub2y J3LnwYEGr7JOwdfFa1kEYAR0R67v0iTIU0A9Jl4l/UMSWeuAkfAgIWdzP8LOhI7kdbRP tyV3UG9oQ5laet3dh4g9LS0shijwmy19hgFEV3KzM0Xyf7Q9lMQ9WdzdpjLEjSdZ+Lsd MjRv3jRF5/F9mwVeEZjCn1pv5Z6s5X7yxejnmgQ11qZXNp7ycewUcisHDnfP40uT8OJ2 q69w== 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 t23-v6si1654389ply.482.2018.03.27.11.02.20; Tue, 27 Mar 2018 11:02:35 -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 S1753379AbeC0SAk (ORCPT + 99 others); Tue, 27 Mar 2018 14:00:40 -0400 Received: from usa-sjc-mx-foss1.foss.arm.com ([217.140.101.70]:33036 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753219AbeC0SAi (ORCPT ); Tue, 27 Mar 2018 14:00:38 -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 3BC641529; Tue, 27 Mar 2018 11:00:38 -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 0C1883F25D; Tue, 27 Mar 2018 11:00:38 -0700 (PDT) Received: by edgewater-inn.cambridge.arm.com (Postfix, from userid 1000) id D79871AE53E5; Tue, 27 Mar 2018 19:00:48 +0100 (BST) Date: Tue, 27 Mar 2018 19:00:48 +0100 From: Will Deacon To: Chintan Pandya Cc: catalin.marinas@arm.com, mark.rutland@arm.com, toshi.kani@hpe.com, arnd@arndb.de, ard.biesheuvel@linaro.org, marc.zyngier@arm.com, james.morse@arm.com, kristina.martsenko@arm.com, takahiro.akashi@linaro.org, gregkh@linuxfoundation.org, tglx@linutronix.de, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, akpm@linux-foundation.org Subject: Re: [PATCH v5 3/4] arm64: Implement page table free interfaces Message-ID: <20180327180048.GJ18435@arm.com> References: <1522157100-16879-1-git-send-email-cpandya@codeaurora.org> <1522157100-16879-4-git-send-email-cpandya@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1522157100-16879-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, On Tue, Mar 27, 2018 at 06:54:59PM +0530, Chintan Pandya wrote: > Implement pud_free_pmd_page() and pmd_free_pte_page(). > > Implementation requires, > 1) Freeing of the un-used next level page tables > 2) Clearing off the current pud/pmd entry > 3) Invalidate TLB which could have previously > valid but not stale entry > > Signed-off-by: Chintan Pandya > --- > V4->V5: > - Using __flush_tlb_kernel_pgtable instead of > flush_tlb_kernel_range > > > arch/arm64/mm/mmu.c | 33 +++++++++++++++++++++++++++++++-- > 1 file changed, 31 insertions(+), 2 deletions(-) > > diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c > index da98828..3552c7a 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,40 @@ int pmd_clear_huge(pmd_t *pmdp) > return 1; > } > > +static int __pmd_free_pte_page(pmd_t *pmd, unsigned long addr, bool tlb_inv) > +{ > + pmd_t *table; > + > + if (pmd_val(*pmd)) { Please can you follow what I did in 20a004e7b017 ("arm64: mm: Use READ_ONCE/WRITE_ONCE when accessing page tables") and: 1. Use consistent naming, so pmd_t * pmdp. 2. Use READ_ONCE to dereference the entry once into a local. Similarly for the pud code below. > + table = __va(pmd_val(*pmd)); > + pmd_clear(pmd); > + if (tlb_inv) > + __flush_tlb_kernel_pgtable(addr); > + > + free_page((unsigned long) table); Hmm. Surely it's only safe to call free_page if !tlb_inv in situations when the page table is already disconnected at a higher level? That doesn't appear to be the case with the function below, which still has the pud installed. What am I missing? > + } > + return 1; > +} > + > int pud_free_pmd_page(pud_t *pud, unsigned long addr) > { > - return pud_none(*pud); > + pmd_t *table; > + int i; > + > + if (pud_val(*pud)) { > + table = __va(pud_val(*pud)); > + for (i = 0; i < PTRS_PER_PMD; i++) > + __pmd_free_pte_page(&table[i], addr + (i * PMD_SIZE), > + false); > + > + pud_clear(pud); > + flush_tlb_kernel_range(addr, addr + PUD_SIZE); Why aren't you using __flush_tlb_kernel_pgtable here? Will