From patchwork Thu Dec 28 11:24:21 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Hanjun Guo X-Patchwork-Id: 122838 Delivered-To: patch@linaro.org Received: by 10.140.22.227 with SMTP id 90csp3333886qgn; Thu, 28 Dec 2017 03:34:00 -0800 (PST) X-Google-Smtp-Source: ACJfBovolDXv0R/21Vm27xQI0mhrejgWLvoGOJOcJnZ2RxWe/zEY5JB+CPWiKPT91ZR38u+lwiZB X-Received: by 10.98.18.157 with SMTP id 29mr31479611pfs.84.1514460840497; Thu, 28 Dec 2017 03:34:00 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1514460840; cv=none; d=google.com; s=arc-20160816; b=BzsXPml3tkNUOXHjWnFRtTb4DLCgQY480BcLrzcMI3ZcO225VoeQARrYTuGYwtHSNi yp4XJbzJXNwGut2GSQnoeogYiwfOE9dNRO1vpABmpVp8ihlaA+MhJ0exBsybBqyGmvl6 jeZKIeGZlWgMj9Q6QfXBv81HAQ2e+P9+kglyOt2UykIRlkmy+VGRXjsONhExzuJLn9Tj L3lfEl36PZVilAkA2f03CuvPZ8ZVpNGk15fSk6qRtKANn/dRFbQz09hZ7v69d6qvdLSE hBLatV8jZy6gJqCmDMdHdh3yGnMIzA6xBHwn0VSzxolklt6g7ig9jH2Pt2FIRBcvW5wK jYoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:message-id:date:subject:cc :to:from:arc-authentication-results; bh=EQHhONGtCTgQ10Ba+9k03pELUEAb2cFOQ4gC+dS8Q/0=; b=nkBMnnkwxR453j1S0ulWiLxUCMkWI6Qu+Yy9ewcivS3fivi8c8RdHTQMozyFokox5k zJDisR96BzRSePrIpguTeWDUEl9x6+HqSh7SzOCbCFg2HBUPefF+q7ThUl0lKHiUn4Al v4KMS9mKbQA3ZE4ulxrffbLwogkKe9Cib9dmPM2iBDdFTNpvPe2q3lQ7wKzYkT0fCU8R uRvpYh46mn0EOD7xW1gAv7XURW5TeNZX5sPj+lmYqefn0RItg0OUKzs7ZgOEv5f0pfxX R2Eg/6DR9mwZfzJ4IanjX5PP0Nes271zIAQBDtCjwJ6xsCBt4h05jqofggnkRiO0lLtE TbTg== 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 k189si23924080pgc.248.2017.12.28.03.34.00; Thu, 28 Dec 2017 03:34:00 -0800 (PST) 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 S1753243AbdL1Ld5 (ORCPT + 28 others); Thu, 28 Dec 2017 06:33:57 -0500 Received: from szxga06-in.huawei.com ([45.249.212.32]:41568 "EHLO huawei.com" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1751372AbdL1Ldz (ORCPT ); Thu, 28 Dec 2017 06:33:55 -0500 Received: from DGGEMS402-HUB.china.huawei.com (unknown [172.30.72.59]) by Forcepoint Email with ESMTP id 682C6A97D3062; Thu, 28 Dec 2017 19:33:40 +0800 (CST) Received: from linux-ibm.site (10.175.102.37) by DGGEMS402-HUB.china.huawei.com (10.3.19.202) with Microsoft SMTP Server id 14.3.361.1; Thu, 28 Dec 2017 19:33:31 +0800 From: Hanjun Guo To: , CC: , , Hanjun Guo , Toshi Kani , Mark Rutland , Will Deacon , Catalin Marinas , Michal Hocko , Andrew Morton , Xuefeng Wang Subject: [RFC patch] ioremap: don't set up huge I/O mappings when p4d/pud/pmd is zero Date: Thu, 28 Dec 2017 19:24:21 +0800 Message-ID: <1514460261-65222-1-git-send-email-guohanjun@huawei.com> X-Mailer: git-send-email 1.7.12.4 MIME-Version: 1.0 X-Originating-IP: [10.175.102.37] X-CFilter-Loop: Reflected Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Hanjun Guo When we using iounmap() to free the 4K mapping, it just clear the PTEs but leave P4D/PUD/PMD unchanged, also will not free the memory of page tables. This will cause issues on ARM64 platform (not sure if other archs have the same issue) for this case: 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. Fix it by skip setting up the huge I/O mappings when p4d/pud/pmd is zero. Reported-by: Lei Li Signed-off-by: Hanjun Guo Cc: Toshi Kani Cc: Mark Rutland Cc: Will Deacon Cc: Catalin Marinas Cc: Michal Hocko Cc: Andrew Morton Cc: Xuefeng Wang --- Not sure if this is the right direction, this patch has a obvious side effect that a mapped address with 4K will not back to 2M. I may miss something and just wrong, so this is just a RFC version, comments are welcomed. lib/ioremap.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) -- 1.7.12.4 diff --git a/lib/ioremap.c b/lib/ioremap.c index b808a39..4e6f19a 100644 --- a/lib/ioremap.c +++ b/lib/ioremap.c @@ -89,7 +89,7 @@ static inline int ioremap_pmd_range(pud_t *pud, unsigned long addr, do { next = pmd_addr_end(addr, end); - if (ioremap_pmd_enabled() && + if (ioremap_pmd_enabled() && pmd_none(*pmd) && ((next - addr) == PMD_SIZE) && IS_ALIGNED(phys_addr + addr, PMD_SIZE)) { if (pmd_set_huge(pmd, phys_addr + addr, prot)) @@ -115,7 +115,7 @@ static inline int ioremap_pud_range(p4d_t *p4d, unsigned long addr, do { next = pud_addr_end(addr, end); - if (ioremap_pud_enabled() && + if (ioremap_pud_enabled() && pud_none(*pud) && ((next - addr) == PUD_SIZE) && IS_ALIGNED(phys_addr + addr, PUD_SIZE)) { if (pud_set_huge(pud, phys_addr + addr, prot)) @@ -141,7 +141,7 @@ static inline int ioremap_p4d_range(pgd_t *pgd, unsigned long addr, do { next = p4d_addr_end(addr, end); - if (ioremap_p4d_enabled() && + if (ioremap_p4d_enabled() && p4d_none(*p4d) && ((next - addr) == P4D_SIZE) && IS_ALIGNED(phys_addr + addr, P4D_SIZE)) { if (p4d_set_huge(p4d, phys_addr + addr, prot))