From: David Hildenbrand <david@redhat.com> To: linux-kernel@vger.kernel.org Cc: linux-mm@kvack.org, linuxppc-dev@lists.ozlabs.org, David Hildenbrand <david@redhat.com>, Andrew Morton <akpm@linux-foundation.org>, "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Michael Ellerman <mpe@ellerman.id.au>, Michal Hocko <mhocko@kernel.org>, Michal Hocko <mhocko@suse.com>, Mike Rapoport <rppt@kernel.org>, Nicholas Piggin <npiggin@gmail.com>, Oscar Salvador <osalvador@suse.de>, Paul Mackerras <paulus@samba.org>, Rashmica Gupta <rashmica.g@gmail.com>, Wei Yang <richard.weiyang@linux.alibaba.com> Subject: [PATCH v2 0/8] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations Date: Wed, 11 Nov 2020 15:53:14 +0100 [thread overview] Message-ID: <20201111145322.15793-1-david@redhat.com> (raw) Based on latest linux/master powernv/memtrace is the only in-kernel user that rips out random memory it never added (doesn't own) in order to allocate memory without a linear mapping. Let's stop abusing memory hot(un)plug infrastructure for that - use alloc_contig_pages() for allocating memory and remove the linear mapping manually. The original idea was discussed in: https://lkml.kernel.org/r/48340e96-7e6b-736f-9e23-d3111b915b6e@redhat.com I only tested via QEMU TCG with a single NUMA node- see patch #8 for more details. Error handling and cleanup handling in memtrace code is a mess - that should definitely get cleaned up sooner or later. Once we have __GFP_ZERO support for alloc_contig_pages(), we can drop manual clearing. I added a TODO for now, so this series can go via the powerpc tree - the __GFP_ZERO change is then better suited via the mm tree, along with support for __GFP_ZERO. v1 -> v2: - Tweaks to patch descriptions - "powernv/memtrace: don't leak kernel memory to user space" -- Added. Reported by Michael. - "powernv/memtrace: fix crashing the kernel when enabling concurrently" -- Added, discovered while testing. - "powerpc/mm: protect linear mapping modifications by a mutex" -- Added. Although we currently won't have concurrency, this is cleaner and future-proof. - "powerepc/book3s64/hash: drop WARN_ON in hash__remove_section_mapping" -- Added. Suggested by Oscar - "powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations" -- Reshuffle the code to make review easier. -- Add a TODO regarding __GFP_ZERO. Adapt to changed page clearing code. -- Use GFP_KERNEL | __GFP_THISNODE | __GFP_NOWARN for allocations. David Hildenbrand (8): powernv/memtrace: don't leak kernel memory to user space powernv/memtrace: fix crashing the kernel when enabling concurrently powerpc/mm: factor out creating/removing linear mapping powerpc/mm: protect linear mapping modifications by a mutex powerpc/mm: print warning in arch_remove_linear_mapping() powerepc/book3s64/hash: drop WARN_ON in hash__remove_section_mapping powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory() powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations arch/powerpc/mm/book3s64/hash_utils.c | 1 - arch/powerpc/mm/mem.c | 53 +++++-- arch/powerpc/platforms/powernv/Kconfig | 8 +- arch/powerpc/platforms/powernv/memtrace.c | 175 ++++++++++------------ include/linux/memory_hotplug.h | 3 + 5 files changed, 125 insertions(+), 115 deletions(-) -- 2.26.2
WARNING: multiple messages have this Message-ID (diff)
From: David Hildenbrand <david@redhat.com> To: linux-kernel@vger.kernel.org Cc: Michal Hocko <mhocko@suse.com>, Wei Yang <richard.weiyang@linux.alibaba.com>, David Hildenbrand <david@redhat.com>, Nicholas Piggin <npiggin@gmail.com>, Michal Hocko <mhocko@kernel.org>, linux-mm@kvack.org, Paul Mackerras <paulus@samba.org>, "Aneesh Kumar K.V" <aneesh.kumar@linux.ibm.com>, Andrew Morton <akpm@linux-foundation.org>, linuxppc-dev@lists.ozlabs.org, Rashmica Gupta <rashmica.g@gmail.com>, Mike Rapoport <rppt@kernel.org>, Oscar Salvador <osalvador@suse.de> Subject: [PATCH v2 0/8] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations Date: Wed, 11 Nov 2020 15:53:14 +0100 [thread overview] Message-ID: <20201111145322.15793-1-david@redhat.com> (raw) Based on latest linux/master powernv/memtrace is the only in-kernel user that rips out random memory it never added (doesn't own) in order to allocate memory without a linear mapping. Let's stop abusing memory hot(un)plug infrastructure for that - use alloc_contig_pages() for allocating memory and remove the linear mapping manually. The original idea was discussed in: https://lkml.kernel.org/r/48340e96-7e6b-736f-9e23-d3111b915b6e@redhat.com I only tested via QEMU TCG with a single NUMA node- see patch #8 for more details. Error handling and cleanup handling in memtrace code is a mess - that should definitely get cleaned up sooner or later. Once we have __GFP_ZERO support for alloc_contig_pages(), we can drop manual clearing. I added a TODO for now, so this series can go via the powerpc tree - the __GFP_ZERO change is then better suited via the mm tree, along with support for __GFP_ZERO. v1 -> v2: - Tweaks to patch descriptions - "powernv/memtrace: don't leak kernel memory to user space" -- Added. Reported by Michael. - "powernv/memtrace: fix crashing the kernel when enabling concurrently" -- Added, discovered while testing. - "powerpc/mm: protect linear mapping modifications by a mutex" -- Added. Although we currently won't have concurrency, this is cleaner and future-proof. - "powerepc/book3s64/hash: drop WARN_ON in hash__remove_section_mapping" -- Added. Suggested by Oscar - "powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations" -- Reshuffle the code to make review easier. -- Add a TODO regarding __GFP_ZERO. Adapt to changed page clearing code. -- Use GFP_KERNEL | __GFP_THISNODE | __GFP_NOWARN for allocations. David Hildenbrand (8): powernv/memtrace: don't leak kernel memory to user space powernv/memtrace: fix crashing the kernel when enabling concurrently powerpc/mm: factor out creating/removing linear mapping powerpc/mm: protect linear mapping modifications by a mutex powerpc/mm: print warning in arch_remove_linear_mapping() powerepc/book3s64/hash: drop WARN_ON in hash__remove_section_mapping powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory() powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations arch/powerpc/mm/book3s64/hash_utils.c | 1 - arch/powerpc/mm/mem.c | 53 +++++-- arch/powerpc/platforms/powernv/Kconfig | 8 +- arch/powerpc/platforms/powernv/memtrace.c | 175 ++++++++++------------ include/linux/memory_hotplug.h | 3 + 5 files changed, 125 insertions(+), 115 deletions(-) -- 2.26.2
next reply other threads:[~2020-11-11 14:53 UTC|newest] Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-11 14:53 David Hildenbrand [this message] 2020-11-11 14:53 ` [PATCH v2 0/8] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations David Hildenbrand 2020-11-11 14:53 ` [PATCH v2 1/8] powernv/memtrace: don't leak kernel memory to user space David Hildenbrand 2020-11-11 14:53 ` David Hildenbrand 2020-11-17 15:13 ` Oscar Salvador 2020-11-17 15:13 ` Oscar Salvador 2020-11-11 14:53 ` [PATCH v2 2/8] powernv/memtrace: fix crashing the kernel when enabling concurrently David Hildenbrand 2020-11-11 14:53 ` David Hildenbrand 2020-11-17 15:22 ` Oscar Salvador 2020-11-17 15:22 ` Oscar Salvador 2020-11-11 14:53 ` [PATCH v2 3/8] powerpc/mm: factor out creating/removing linear mapping David Hildenbrand 2020-11-11 14:53 ` David Hildenbrand 2020-11-17 15:27 ` Oscar Salvador 2020-11-17 15:27 ` Oscar Salvador 2020-11-11 14:53 ` [PATCH v2 4/8] powerpc/mm: protect linear mapping modifications by a mutex David Hildenbrand 2020-11-11 14:53 ` David Hildenbrand 2020-11-17 15:37 ` Oscar Salvador 2020-11-17 15:37 ` Oscar Salvador 2020-11-17 15:46 ` David Hildenbrand 2020-11-17 15:46 ` David Hildenbrand 2020-11-11 14:53 ` [PATCH v2 5/8] powerpc/mm: print warning in arch_remove_linear_mapping() David Hildenbrand 2020-11-11 14:53 ` David Hildenbrand 2020-11-11 14:53 ` [PATCH v2 6/8] powerepc/book3s64/hash: drop WARN_ON in hash__remove_section_mapping David Hildenbrand 2020-11-11 14:53 ` David Hildenbrand 2020-11-17 15:45 ` Oscar Salvador 2020-11-17 15:45 ` Oscar Salvador 2020-11-11 14:53 ` [PATCH v2 7/8] powerpc/mm: remove linear mapping if __add_pages() fails in arch_add_memory() David Hildenbrand 2020-11-11 14:53 ` David Hildenbrand 2020-11-17 15:51 ` Oscar Salvador 2020-11-17 15:51 ` Oscar Salvador 2020-11-17 15:53 ` David Hildenbrand 2020-11-17 15:53 ` David Hildenbrand 2020-11-18 2:00 ` Michael Ellerman 2020-11-18 2:00 ` Michael Ellerman 2020-11-11 14:53 ` [PATCH v2 8/8] powernv/memtrace: don't abuse memory hot(un)plug infrastructure for memory allocations David Hildenbrand 2020-11-11 14:53 ` David Hildenbrand 2020-11-17 16:45 ` Oscar Salvador 2020-11-17 16:45 ` Oscar Salvador 2020-11-25 11:57 ` [PATCH v2 0/8] " Michael Ellerman 2020-11-25 11:57 ` Michael Ellerman
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=20201111145322.15793-1-david@redhat.com \ --to=david@redhat.com \ --cc=akpm@linux-foundation.org \ --cc=aneesh.kumar@linux.ibm.com \ --cc=benh@kernel.crashing.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-mm@kvack.org \ --cc=linuxppc-dev@lists.ozlabs.org \ --cc=mhocko@kernel.org \ --cc=mhocko@suse.com \ --cc=mpe@ellerman.id.au \ --cc=npiggin@gmail.com \ --cc=osalvador@suse.de \ --cc=paulus@samba.org \ --cc=rashmica.g@gmail.com \ --cc=richard.weiyang@linux.alibaba.com \ --cc=rppt@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.