Received: by 10.213.65.68 with SMTP id h4csp1285407imn; Wed, 14 Mar 2018 15:39:43 -0700 (PDT) X-Google-Smtp-Source: AG47ELue+IlxWHT35hzJYaBTb4QVV6PsWxiyYrKfG0+Ki89MXs5ekwNXEIEjNHZmWUWs2HgH9g1Y X-Received: by 2002:a17:902:d90b:: with SMTP id c11-v6mr5752107plz.200.1521067183459; Wed, 14 Mar 2018 15:39:43 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521067183; cv=none; d=google.com; s=arc-20160816; b=CR54jxg3fUoPqfb8BFfpVs72uJE8mZAwWus1YDGsSudWgGOLvmzS55bYQGu3PseAOW cJ21jpgNaAicVx3e75k22JHnlbV+GLwZZ4G8s62RnrZkzbqz7BVYhQcvQrzv5ZX9iUhv tlL5ns2Tthd71EtzhYWiGBMi8V5EI6x8y5jxKJQZLvJagMN6cDpkj4cEWn9kx+NXYTQt WhXkjjR2X51OMcbiL39lR0o3Y7335QAFllQ4fP/RV4wv0KcR4CF2tVNoSLs2SBPchqFj aVP/CY2ZtXSzL43nVNe11PEh9R5KiaATkDxCtf0GiP/+9pt0BVZluFJQu4PQ3IretRxm wwoQ== 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:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date :arc-authentication-results; bh=RvkcaMVJoUPVHv0T6cyKEWp2L0GK3EVNHRwaAxdzgQw=; b=rExqeFatHFjat2AcbzByilhxqI1yvNBU4fAn38esSkkPFrUkZWDKZ5+LoypmYeVn1P rjMwg3dGjfuXZFZEQkMp+C+hmC7MR9i4pr55nhEYqropEYYu6q0KZ0Me+4+2ul+tUXwt BQ/eZNwbbU0g6CWmkYsKKISlTVZS1VXp/Gr0vlb058eZf2PdFmhAR5R6axaSge2cgtUF WHGqtf9OMlhHqRgNTNIbqwkvnJQJhxsqboY9IqutOGbI1Uv4f1q+c8Vj1+Zjp9y73iFD dbxSjmhX0VUtu8c/I7PmGfozCzO056mjnBrwwRVvYegebE3RNCrGWbIwKAjkIX0cI68X M8Mg== 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 3-v6si2621275pll.585.2018.03.14.15.39.29; Wed, 14 Mar 2018 15:39:43 -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 S1751599AbeCNWii (ORCPT + 99 others); Wed, 14 Mar 2018 18:38:38 -0400 Received: from mail.linuxfoundation.org ([140.211.169.12]:43414 "EHLO mail.linuxfoundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751314AbeCNWih (ORCPT ); Wed, 14 Mar 2018 18:38:37 -0400 Received: from akpm3.svl.corp.google.com (unknown [104.133.9.71]) by mail.linuxfoundation.org (Postfix) with ESMTPSA id 950EAC19; Wed, 14 Mar 2018 22:38:36 +0000 (UTC) Date: Wed, 14 Mar 2018 15:38:35 -0700 From: Andrew Morton To: Toshi Kani Cc: mhocko@suse.com, tglx@linutronix.de, mingo@redhat.com, hpa@zytor.com, bp@suse.de, catalin.marinas@arm.com, guohanjun@huawei.com, will.deacon@arm.com, wxf.wang@hisilicon.com, willy@infradead.org, cpandya@codeaurora.org, linux-mm@kvack.org, x86@kernel.org, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, stable@vger.kernel.org Subject: Re: [PATCH v2 1/2] mm/vmalloc: Add interfaces to free unmapped page table Message-Id: <20180314153835.68e75da3fdc18b27ad0e290c@linux-foundation.org> In-Reply-To: <20180314180155.19492-2-toshi.kani@hpe.com> References: <20180314180155.19492-1-toshi.kani@hpe.com> <20180314180155.19492-2-toshi.kani@hpe.com> X-Mailer: Sylpheed 3.6.0 (GTK+ 2.24.31; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 14 Mar 2018 12:01:54 -0600 Toshi Kani wrote: > On architectures with CONFIG_HAVE_ARCH_HUGE_VMAP set, ioremap() > may create pud/pmd mappings. Kernel panic was observed on arm64 > systems with Cortex-A75 in the following steps as described by > Hanjun Guo. > > 1. ioremap a 4K size, valid page table will build, > 2. iounmap it, pte0 will set to 0; > 3. ioremap the same address with 2M size, pgd/pmd is unchanged, > then set the a new value for pmd; > 4. pte0 is leaked; > 5. CPU may meet exception because the old pmd is still in TLB, > which will lead to kernel panic. > > This panic is not reproducible on x86. INVLPG, called from iounmap, > purges all levels of entries associated with purged address on x86. > x86 still has memory leak. > > The patch changes the ioremap path to free unmapped page table(s) since > doing so in the unmap path has the following issues: > > - The iounmap() path is shared with vunmap(). Since vmap() only > supports pte mappings, making vunmap() to free a pte page is an > overhead for regular vmap users as they do not need a pte page > freed up. > - Checking if all entries in a pte page are cleared in the unmap path > is racy, and serializing this check is expensive. > - The unmap path calls free_vmap_area_noflush() to do lazy TLB purges. > Clearing a pud/pmd entry before the lazy TLB purges needs extra TLB > purge. > > Add two interfaces, pud_free_pmd_page() and pmd_free_pte_page(), > which clear a given pud/pmd entry and free up a page for the lower > level entries. > > This patch implements their stub functions on x86 and arm64, which > work as workaround. > whoops. --- a/include/asm-generic/pgtable.h~mm-vmalloc-add-interfaces-to-free-unmapped-page-table-fix +++ a/include/asm-generic/pgtable.h @@ -1014,7 +1014,7 @@ static inline int pud_free_pmd_page(pud_ { return 0; } -static inline int pmd_free_pte_page(pud_t *pmd) +static inline int pmd_free_pte_page(pmd_t *pmd) { return 0; } _