Received: by 2002:a25:ab43:0:0:0:0:0 with SMTP id u61csp220607ybi; Tue, 18 Jun 2019 21:18:41 -0700 (PDT) X-Google-Smtp-Source: APXvYqwrpFIGMOycSgwC3bXj/TE2c5bR0g+j52SFLAD7365LQFR27Y+FXDqYuvHULx0LVOKg8N5H X-Received: by 2002:a17:902:9a84:: with SMTP id w4mr15415382plp.160.1560917921349; Tue, 18 Jun 2019 21:18:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1560917921; cv=none; d=google.com; s=arc-20160816; b=YbRayxQSPd6bUJftmfkpXtBzChZo2MgOYcJIdRaB+USbmxLgErYfOSS2NzTYEuJdvj tzDdOKjScahBrMwQObVntQYzvfvPjRt7UOT5Vg8JhSkiTjwHlAMyh/k//CcoDEH4Nmix wkxugEVt1UcUF1wCIeOFU/ueTA2JfkGpEosiIdxqZWF48udLGotwgMfgFl8emr7qM/7s eZUH1g2E8sBmhFOEBpzTmWpgFc6ezLmN+H48o4oyeaqdtDzUGxPIWlMcxjSaURHboDNc gaVDViSJrHEwltKYzvdITnit+S9k4E3zCs83SR2OxJFMd3vstRb7cEfvyQqf13lAikXB TLtQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from; bh=GlOBlEcIXkjl+TiR1o4jafzqgo8fD8vSAH8C3FJFjlA=; b=xfU4dljI4kYg0Y7wB1N/SIhEAUgwC/tdDWdcmIYtBLSFSyjBRLKxRqgNYmfrSF082d CkxXwm+FXDFq8j6ZUQHH/ZsZciwcmeQZ4sbi2eyoTaz/6/L67TgbHUdXyNK8XVtqHht3 CtA7AinxMAXLw+fduZrr2oKhnsBDPpiPNLYafliqE0R4wMYAPyDIp3KaM/uHh5fj0ImJ 9vFMOT4nKVdjzFdiglJLF5qfvSGb8kZgjb+uwghEvxLemzrKkT3DHurFz538PH2+tIAM zLbvFCdh/QokfWPXCCcmo1n15z/r4Ag3MSIQb8n6arz7q7xZUE6vI/+ez3nBjNnSuFIp 7SlQ== 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 204si2149816pgh.553.2019.06.18.21.18.26; Tue, 18 Jun 2019 21:18:41 -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 S1729050AbfFSERr (ORCPT + 99 others); Wed, 19 Jun 2019 00:17:47 -0400 Received: from foss.arm.com ([217.140.110.172]:46730 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725916AbfFSERq (ORCPT ); Wed, 19 Jun 2019 00:17:46 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C36CA360; Tue, 18 Jun 2019 21:17:45 -0700 (PDT) Received: from p8cg001049571a15.blr.arm.com (p8cg001049571a15.blr.arm.com [10.162.43.130]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPA id BEC413F718; Tue, 18 Jun 2019 21:17:39 -0700 (PDT) From: Anshuman Khandual To: linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, catalin.marinas@arm.com, will.deacon@arm.com Cc: mark.rutland@arm.com, mhocko@suse.com, ira.weiny@intel.com, david@redhat.com, cai@lca.pw, logang@deltatee.com, james.morse@arm.com, cpandya@codeaurora.org, arunks@codeaurora.org, dan.j.williams@intel.com, mgorman@techsingularity.net, osalvador@suse.de, ard.biesheuvel@arm.com, steve.capper@arm.com Subject: [PATCH V6 2/3] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump Date: Wed, 19 Jun 2019 09:47:39 +0530 Message-Id: <1560917860-26169-3-git-send-email-anshuman.khandual@arm.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1560917860-26169-1-git-send-email-anshuman.khandual@arm.com> References: <1560917860-26169-1-git-send-email-anshuman.khandual@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The arm64 page table dump code can race with concurrent modification of the kernel page tables. When a leaf entries are modified concurrently, the dump code may log stale or inconsistent information for a VA range, but this is otherwise not harmful. When intermediate levels of table are freed, the dump code will continue to use memory which has been freed and potentially reallocated for another purpose. In such cases, the dump code may dereference bogus addresses, leading to a number of potential problems. Intermediate levels of table may by freed during memory hot-remove, which will be enabled by a subsequent patch. To avoid racing with this, take the memory hotplug lock when walking the kernel page table. Acked-by: David Hildenbrand Acked-by: Mark Rutland Signed-off-by: Anshuman Khandual --- arch/arm64/mm/ptdump_debugfs.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/arch/arm64/mm/ptdump_debugfs.c b/arch/arm64/mm/ptdump_debugfs.c index 064163f..b5eebc8 100644 --- a/arch/arm64/mm/ptdump_debugfs.c +++ b/arch/arm64/mm/ptdump_debugfs.c @@ -1,5 +1,6 @@ // SPDX-License-Identifier: GPL-2.0 #include +#include #include #include @@ -7,7 +8,10 @@ static int ptdump_show(struct seq_file *m, void *v) { struct ptdump_info *info = m->private; + + get_online_mems(); ptdump_walk_pgd(m, info); + put_online_mems(); return 0; } DEFINE_SHOW_ATTRIBUTE(ptdump); -- 2.7.4