Received: by 10.213.65.68 with SMTP id h4csp850728imn; Wed, 14 Mar 2018 01:50:22 -0700 (PDT) X-Google-Smtp-Source: AG47ELvQz5NuQ6fsBzPx8FqI6dweJJwBZm1L424ejg6oO4seac5oZNZCyQYhV8nB0m9LNPx1W888 X-Received: by 10.99.63.14 with SMTP id m14mr3006594pga.174.1521017422208; Wed, 14 Mar 2018 01:50:22 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521017422; cv=none; d=google.com; s=arc-20160816; b=c3f/uZuU3bJ2VYgcEocLina36BB2RPL96PBJSgF1x/KtDKmh5IBtbmdVfyidhFqf6B WSxCSWP3J/SwzjIhyEDiK2RV+zIhv5F8YWFSU1Y8ZHiduwJgrIz2iPa79f2vq9xJImAR JjkL58k8IOtMDA7T0e+ODDnvd/heXPHw1nmFLrgpQQw68bQw6xKeTgDLInIQWY8crTDV jFP89NKmAKFGuoj0gBAz0n11KobVU2pljsFhGQKlLXiOOr/OgEO/ceXjFZlVCYeOrmrs RLy3iWSteMUIwIYbgQ13b9BVpVmC8UP360fUuLcj1rPzxMnQAD/+GviZPwzOhm2f+nwV RLYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :dmarc-filter:dkim-signature:dkim-signature :arc-authentication-results; bh=BVw4iuMiNOGMGY33ozK4SgLXHGQKcr05wxlxFQTGaKY=; b=HiZ76of/hCVIXGEkxPl3mv7juuGy2brqfCev/gmS28mQX7uh49BKuYP4ZomGRfCNGn Asy1uNZueiHX0rZVIkDK07seDH+yEbmFbspEprXmF/iiQ6x28XrRJv6qY5TY/AU70hma w5kmGH2guk8H+EqV2gaOFUZRJ93WAnMwdUAnRBZ/POMLYq71hXsyRWZNp+3G5QR+SdGg RIYbYNIIzMB29gzkpPQ43BU+0F+UolaIZT0jcM1PnBUPsvyNERIvZC967kENY1mPa4ty W7BoaDGXcP5bx4SX8HBuZAonYtAGhWpgdg6wcnmZiY/aQzEFdWL3swy5+jnek4JTf7T1 atgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@codeaurora.org header.s=default header.b=D4ozXUjL; dkim=pass header.i=@codeaurora.org header.s=default header.b=kAWomCRF; 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 y15si1721334pfb.346.2018.03.14.01.50.08; Wed, 14 Mar 2018 01:50:22 -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=D4ozXUjL; dkim=pass header.i=@codeaurora.org header.s=default header.b=kAWomCRF; 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 S1753271AbeCNIsm (ORCPT + 99 others); Wed, 14 Mar 2018 04:48:42 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:58274 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750751AbeCNIsk (ORCPT ); Wed, 14 Mar 2018 04:48:40 -0400 Received: by smtp.codeaurora.org (Postfix, from userid 1000) id 5B60660592; Wed, 14 Mar 2018 08:48:40 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1521017320; bh=xSqLL66ttbDJPCkfrQklTg5jKPnRcc+T+UyuKyrSSB4=; h=From:To:Cc:Subject:Date:From; b=D4ozXUjLzxfhgVMFmrGal6977d0TJvWZfhTCFcAnsgN6U23nYQHyNN2blWly4lIeC DZ041SI6vzp2f95H81Iv7D385xnWqY+FrfIEwrpsaWHRc7/j3UyFNo0kQsdo2rVt6D PuClN/Vrav/md1I7mjEbbl9WAW1Ia8GTqVFBNGdM= 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 cpandya-linux.qualcomm.com (blr-c-bdr-fw-01_globalnat_allzones-outside.qualcomm.com [103.229.19.19]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: cpandya@smtp.codeaurora.org) by smtp.codeaurora.org (Postfix) with ESMTPSA id 5205E6016D; Wed, 14 Mar 2018 08:48:34 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=codeaurora.org; s=default; t=1521017318; bh=xSqLL66ttbDJPCkfrQklTg5jKPnRcc+T+UyuKyrSSB4=; h=From:To:Cc:Subject:Date:From; b=kAWomCRFTwaIB1pWv/CTxgklqRaj/lPSOpGvrTkbibOItRp6lzHgDzteqMbNntPVD Eg6WggVVCTMsw5qQpr5wVCEIKQDI/VlMNv3Cc17ngEcaOrRpduUOLsYBCzCvljTtVP TfJRi37BOAg5oiBSPtlA3EvD9GCi06ou00KwC28Y= DMARC-Filter: OpenDMARC Filter v1.3.2 smtp.codeaurora.org 5205E6016D 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 From: Chintan Pandya To: catalin.marinas@arm.com, will.deacon@arm.com, arnd@arndb.de Cc: mark.rutland@arm.com, 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, toshi.kani@hpe.com, Chintan Pandya Subject: [PATCH v1 0/4] Fix issues with huge mapping in ioremap Date: Wed, 14 Mar 2018 14:18:21 +0530 Message-Id: <1521017305-28518-1-git-send-email-cpandya@codeaurora.org> X-Mailer: git-send-email 1.9.1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Note: I was working on these patches for quite sometime and realized that Toshi Kani has shared some patches addressing the same isssue with subject "[PATCH 0/2] fix memory leak / panic in ioremap huge pages". I've taken slightly different approach here, so sending to the list, finally. This patch series attempts to fix the issue described in this discussion: https://lkml.org/lkml/2017/12/23/3 In summary, CONFIG_HAVE_ARCH_HUGE_VMAP has 2 issues observed on ARM64 1. Stale TLB entries 2. Page table leaks Will Deacon has by-passed huge mapping for ARM64 until these issues are fixed properly. I've tested these patches on ARM64 based SDM845 with 4.9 kernel. Hanjun Guo shared test-case to reproduce this issue in https://patchwork.kernel.org/patch/10134581/ However, I had no luck reproducing this issue with exactly this test. I added some more code to reproduce and here is my test which surfaces this issue in some five hours of testing. Test Code: #define pr_fmt(fmt) "IOREMAP_TEST: " fmt #include #include #include #include #include #include #include #include static int io_remap_test(void *arg) { phys_addr_t phy_addr_1 = 0x98000000; unsigned long block_size = 0x200000; unsigned long total_size = 0x400000; unsigned long va_addr_3; unsigned long va_addr_4; struct vm_struct *area; /* * run this test for 10 hours */ u32 times_ms = 10 * 60 * 60 * 1000; unsigned long timeout = jiffies + msecs_to_jiffies(times_ms); int rand_type; int rand_value; u32 mem_size; int i; area = get_vm_area(total_size, VM_IOREMAP); va_addr_3 = (unsigned long)area->addr; va_addr_4 = va_addr_3 + block_size; pr_err("Virtual area %lx -- %lx\n", va_addr_3, va_addr_3 + total_size); ioremap_page_range(va_addr_3, va_addr_3 + block_size, phy_addr_1, __pgprot(PROT_DEVICE_nGnRE)); pr_err("My tests will run now 2\n"); do { get_random_bytes(&rand_value, sizeof(u32)); rand_type = rand_value % 6; switch (rand_type) { case 0: mem_size = 0x1000; break; case 1: mem_size = 0x8000; break; case 2: mem_size = 0x200000; break; case 3: mem_size = 0x30000; break; case 4: mem_size = 0x10000; break; case 5: mem_size = 0x40000; break; default: mem_size = 0x4000; break; } /* * Prompt TLB to speculatively pre-fetch */ readq(va_addr_3 + block_size - 0x20); readq(va_addr_3 + block_size - 0x18); readq(va_addr_3 + block_size - 0x10); readq(va_addr_3 + block_size - 0x8); ioremap_page_range(va_addr_4, va_addr_4 + mem_size, phy_addr_1, __pgprot(PROT_DEVICE_nGnRE)); if (mem_size >= 0x200000 && !(rand_value%10000)) { schedule(); pr_err("possible error case\n"); } /* * Make CPU aware about our access pattern * Also, these accesses should lead to crash */ for (i = 0; i < 5; i++ ) { readq(va_addr_3 + block_size - 0x20); readq(va_addr_3 + block_size - 0x18); readq(va_addr_3 + block_size - 0x10); readq(va_addr_3 + block_size - 0x8); // Crash is expected here readq(va_addr_4); readq(va_addr_4 + 0x8); readq(va_addr_4 + 0x10); readq(va_addr_4 + 0x18); readq(va_addr_4 + 0x20); } unmap_kernel_range(va_addr_4, mem_size); } while (time_before(jiffies, timeout)); pr_err("my tests ended now\n"); return 0; } static int __init ioremap_testing_init(void) { struct task_struct *t; pr_err("my tests will run now 1\n"); t = kthread_create(&io_remap_test, NULL, "ioremap-testing"); /* * Do this so that we can run this thread on GOLD cores */ kthread_bind(t, 6); wake_up_process(t); return 0; } late_initcall(ioremap_testing_init); Chintan Pandya (4): asm/tlbflush: Add flush_tlb_pgtable() for ARM64 ioremap: Invalidate TLB after huge mappings arm64: Fix the page leak in pud/pmd_set_huge Revert "arm64: Enforce BBM for huge IO/VMAP mappings" arch/arm64/include/asm/tlbflush.h | 5 +++++ arch/arm64/mm/mmu.c | 17 ++++++++--------- include/asm-generic/tlb.h | 6 ++++++ lib/ioremap.c | 9 +++++++-- 4 files changed, 26 insertions(+), 11 deletions(-) -- Qualcomm India Private Limited, on behalf of Qualcomm Innovation Center, Inc., is a member of Code Aurora Forum, a Linux Foundation Collaborative Project