From: Anshuman Khandual <anshuman.khandual@arm.com> To: Balbir Singh <bsingharora@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, catalin.marinas@arm.com, will@kernel.org Cc: mark.rutland@arm.com, mhocko@suse.com, ira.weiny@intel.com, david@redhat.com, cai@lca.pw, logang@deltatee.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, broonie@kernel.org, valentin.schneider@arm.com, Robin.Murphy@arm.com, steven.price@arm.com, suzuki.poulose@arm.com Subject: Re: [PATCH V7 2/3] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump Date: Wed, 18 Sep 2019 14:42:47 +0530 [thread overview] Message-ID: <8e47831f-c28e-a174-24b3-b3bbf1f365ec@arm.com> (raw) In-Reply-To: <66922798-9de7-a230-8548-1f205e79ea50@gmail.com> On 09/15/2019 08:05 AM, Balbir Singh wrote: > > > On 3/9/19 7:45 pm, Anshuman Khandual wrote: >> 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 <david@redhat.com> >> Acked-by: Mark Rutland <mark.rutland@arm.com> >> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> >> --- >> 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 064163f25592..b5eebc8c4924 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 <linux/debugfs.h> >> +#include <linux/memory_hotplug.h> >> #include <linux/seq_file.h> >> >> #include <asm/ptdump.h> >> @@ -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(); > > Looks sane, BTW, checking other arches they might have the same race. The problem can be present on other architectures which can dump kernel page table during memory hot-remove operation where it actually frees up page table pages. If there is no freeing involved the race condition here could cause inconsistent or garbage information capture for a given VA range. Same is true even for concurrent vmalloc() operations as well. But removal of page tables pages can make it worse. Freeing page table pages during hot-remove is a platform decision, so would be adding these locks while walking kernel page table during ptdump. > Is there anything special about the arch? AFAICS, no. > > Acked-by: Balbir Singh <bsingharora@gmail.com> > >
WARNING: multiple messages have this Message-ID (diff)
From: Anshuman Khandual <anshuman.khandual@arm.com> To: Balbir Singh <bsingharora@gmail.com>, linux-mm@kvack.org, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org, akpm@linux-foundation.org, catalin.marinas@arm.com, will@kernel.org Cc: mark.rutland@arm.com, mhocko@suse.com, david@redhat.com, ira.weiny@intel.com, steve.capper@arm.com, mgorman@techsingularity.net, steven.price@arm.com, broonie@kernel.org, cai@lca.pw, ard.biesheuvel@arm.com, cpandya@codeaurora.org, arunks@codeaurora.org, dan.j.williams@intel.com, Robin.Murphy@arm.com, logang@deltatee.com, valentin.schneider@arm.com, suzuki.poulose@arm.com, osalvador@suse.de Subject: Re: [PATCH V7 2/3] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump Date: Wed, 18 Sep 2019 14:42:47 +0530 [thread overview] Message-ID: <8e47831f-c28e-a174-24b3-b3bbf1f365ec@arm.com> (raw) In-Reply-To: <66922798-9de7-a230-8548-1f205e79ea50@gmail.com> On 09/15/2019 08:05 AM, Balbir Singh wrote: > > > On 3/9/19 7:45 pm, Anshuman Khandual wrote: >> 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 <david@redhat.com> >> Acked-by: Mark Rutland <mark.rutland@arm.com> >> Signed-off-by: Anshuman Khandual <anshuman.khandual@arm.com> >> --- >> 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 064163f25592..b5eebc8c4924 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 <linux/debugfs.h> >> +#include <linux/memory_hotplug.h> >> #include <linux/seq_file.h> >> >> #include <asm/ptdump.h> >> @@ -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(); > > Looks sane, BTW, checking other arches they might have the same race. The problem can be present on other architectures which can dump kernel page table during memory hot-remove operation where it actually frees up page table pages. If there is no freeing involved the race condition here could cause inconsistent or garbage information capture for a given VA range. Same is true even for concurrent vmalloc() operations as well. But removal of page tables pages can make it worse. Freeing page table pages during hot-remove is a platform decision, so would be adding these locks while walking kernel page table during ptdump. > Is there anything special about the arch? AFAICS, no. > > Acked-by: Balbir Singh <bsingharora@gmail.com> > > _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2019-09-18 9:12 UTC|newest] Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-09-03 9:45 [PATCH V7 0/3] arm64/mm: Enable memory hot remove Anshuman Khandual 2019-09-03 9:45 ` Anshuman Khandual 2019-09-03 9:45 ` [PATCH V7 1/3] mm/hotplug: Reorder memblock_[free|remove]() calls in try_remove_memory() Anshuman Khandual 2019-09-03 9:45 ` Anshuman Khandual 2019-09-04 8:16 ` David Hildenbrand 2019-09-04 8:16 ` David Hildenbrand 2019-09-05 4:27 ` Anshuman Khandual 2019-09-05 4:27 ` Anshuman Khandual 2019-09-16 1:44 ` Balbir Singh 2019-09-16 1:44 ` Balbir Singh 2019-09-18 9:28 ` Anshuman Khandual 2019-09-18 9:28 ` Anshuman Khandual 2019-09-03 9:45 ` [PATCH V7 2/3] arm64/mm: Hold memory hotplug lock while walking for kernel page table dump Anshuman Khandual 2019-09-03 9:45 ` Anshuman Khandual 2019-09-15 2:35 ` Balbir Singh 2019-09-15 2:35 ` Balbir Singh 2019-09-18 9:12 ` Anshuman Khandual [this message] 2019-09-18 9:12 ` Anshuman Khandual 2019-09-03 9:45 ` [PATCH V7 3/3] arm64/mm: Enable memory hot remove Anshuman Khandual 2019-09-03 9:45 ` Anshuman Khandual 2019-09-10 16:17 ` Catalin Marinas 2019-09-10 16:17 ` Catalin Marinas 2019-09-11 10:31 ` David Hildenbrand 2019-09-11 10:31 ` David Hildenbrand 2019-09-12 4:28 ` Anshuman Khandual 2019-09-12 4:28 ` Anshuman Khandual 2019-09-12 8:37 ` Anshuman Khandual 2019-09-12 8:37 ` Anshuman Khandual 2019-09-12 20:15 ` Catalin Marinas 2019-09-12 20:15 ` Catalin Marinas 2019-09-13 5:58 ` Anshuman Khandual 2019-09-13 5:58 ` Anshuman Khandual 2019-09-13 10:09 ` Catalin Marinas 2019-09-13 10:09 ` Catalin Marinas 2019-09-17 4:36 ` Anshuman Khandual 2019-09-17 4:36 ` Anshuman Khandual 2019-09-17 15:08 ` Catalin Marinas 2019-09-17 15:08 ` Catalin Marinas
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=8e47831f-c28e-a174-24b3-b3bbf1f365ec@arm.com \ --to=anshuman.khandual@arm.com \ --cc=Robin.Murphy@arm.com \ --cc=akpm@linux-foundation.org \ --cc=ard.biesheuvel@arm.com \ --cc=arunks@codeaurora.org \ --cc=broonie@kernel.org \ --cc=bsingharora@gmail.com \ --cc=cai@lca.pw \ --cc=catalin.marinas@arm.com \ --cc=cpandya@codeaurora.org \ --cc=dan.j.williams@intel.com \ --cc=david@redhat.com \ --cc=ira.weiny@intel.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=logang@deltatee.com \ --cc=mark.rutland@arm.com \ --cc=mgorman@techsingularity.net \ --cc=mhocko@suse.com \ --cc=osalvador@suse.de \ --cc=steve.capper@arm.com \ --cc=steven.price@arm.com \ --cc=suzuki.poulose@arm.com \ --cc=valentin.schneider@arm.com \ --cc=will@kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.