From: Mike Rapoport <rppt@kernel.org>
To: linux-kernel@vger.kernel.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
Catalin Marinas <catalin.marinas@arm.com>,
Christophe Leroy <christophe.leroy@csgroup.eu>,
"David S. Miller" <davem@davemloft.net>,
Dinh Nguyen <dinguyen@kernel.org>,
Heiko Carstens <hca@linux.ibm.com>, Helge Deller <deller@gmx.de>,
Huacai Chen <chenhuacai@kernel.org>,
Kent Overstreet <kent.overstreet@linux.dev>,
Luis Chamberlain <mcgrof@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Michael Ellerman <mpe@ellerman.id.au>,
Mike Rapoport <rppt@kernel.org>,
Nadav Amit <nadav.amit@gmail.com>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Puranjay Mohan <puranjay12@gmail.com>,
Rick Edgecombe <rick.p.edgecombe@intel.com>,
Russell King <linux@armlinux.org.uk>, Song Liu <song@kernel.org>,
Steven Rostedt <rostedt@goodmis.org>,
Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Thomas Gleixner <tglx@linutronix.de>,
Will Deacon <will@kernel.org>,
bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-mips@vger.kernel.org, linux-mm@kvack.org,
linux-modules@vger.kernel.org, linux-parisc@vger.kernel.org,
linux-riscv@lists.infradead.org, linux-s390@vger.kernel.org,
linux-trace-kernel@vger.kernel.org,
linuxppc-dev@lists.ozlabs.org, loongarch@lists.linux.dev,
netdev@vger.kernel.org, sparclinux@vger.kernel.org,
x86@kernel.org
Subject: [PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc()
Date: Fri, 16 Jun 2023 11:50:32 +0300 [thread overview]
Message-ID: <20230616085038.4121892-7-rppt@kernel.org> (raw)
In-Reply-To: <20230616085038.4121892-1-rppt@kernel.org>
From: "Mike Rapoport (IBM)" <rppt@kernel.org>
Data related to code allocations, such as module data section, need to
comply with architecture constraints for its placement and its
allocation right now was done using execmem_text_alloc().
Create a dedicated API for allocating data related to code allocations
and allow architectures to define address ranges for data allocations.
Since currently this is only relevant for powerpc variants that use the
VMALLOC address space for module data allocations, automatically reuse
address ranges defined for text unless address range for data is
explicitly defined by an architecture.
With separation of code and data allocations, data sections of the
modules are now mapped as PAGE_KERNEL rather than PAGE_KERNEL_EXEC which
was a default on many architectures.
Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
---
arch/powerpc/kernel/module.c | 8 +++++++
include/linux/execmem.h | 18 +++++++++++++++
kernel/module/main.c | 15 +++----------
mm/execmem.c | 43 ++++++++++++++++++++++++++++++++++++
4 files changed, 72 insertions(+), 12 deletions(-)
diff --git a/arch/powerpc/kernel/module.c b/arch/powerpc/kernel/module.c
index ba7abff77d98..4c6c15bf3947 100644
--- a/arch/powerpc/kernel/module.c
+++ b/arch/powerpc/kernel/module.c
@@ -103,6 +103,10 @@ struct execmem_params __init *execmem_arch_params(void)
{
pgprot_t prot = strict_module_rwx_enabled() ? PAGE_KERNEL : PAGE_KERNEL_EXEC;
+ /*
+ * BOOK3S_32 and 8xx define MODULES_VADDR for text allocations and
+ * allow allocating data in the entire vmalloc space
+ */
#ifdef MODULES_VADDR
unsigned long limit = (unsigned long)_etext - SZ_32M;
@@ -116,6 +120,10 @@ struct execmem_params __init *execmem_arch_params(void)
execmem_params.modules.text.start = MODULES_VADDR;
execmem_params.modules.text.end = MODULES_END;
}
+ execmem_params.modules.data.start = VMALLOC_START;
+ execmem_params.modules.data.end = VMALLOC_END;
+ execmem_params.modules.data.pgprot = PAGE_KERNEL;
+ execmem_params.modules.data.alignment = 1;
#else
execmem_params.modules.text.start = VMALLOC_START;
execmem_params.modules.text.end = VMALLOC_END;
diff --git a/include/linux/execmem.h b/include/linux/execmem.h
index b9a97fcdf3c5..2e1221310d13 100644
--- a/include/linux/execmem.h
+++ b/include/linux/execmem.h
@@ -44,10 +44,12 @@ enum execmem_module_flags {
* space
* @flags: options for module memory allocations
* @text: address range for text allocations
+ * @data: address range for data allocations
*/
struct execmem_modules_range {
enum execmem_module_flags flags;
struct execmem_range text;
+ struct execmem_range data;
};
/**
@@ -89,6 +91,22 @@ struct execmem_params *execmem_arch_params(void);
*/
void *execmem_text_alloc(size_t size);
+/**
+ * execmem_data_alloc - allocate memory for data coupled to code
+ * @size: how many bytes of memory are required
+ *
+ * Allocates memory that will contain data copupled with executable code,
+ * like data sections in kernel modules.
+ *
+ * The memory will have protections defined by architecture.
+ *
+ * The allocated memory will reside in an area that does not impose
+ * restrictions on the addressing modes.
+ *
+ * Return: a pointer to the allocated memory or %NULL
+ */
+void *execmem_data_alloc(size_t size);
+
/**
* execmem_free - free executable memory
* @ptr: pointer to the memory that should be freed
diff --git a/kernel/module/main.c b/kernel/module/main.c
index b445c5ad863a..d6582bfec1f6 100644
--- a/kernel/module/main.c
+++ b/kernel/module/main.c
@@ -1195,25 +1195,16 @@ void __weak module_arch_freeing_init(struct module *mod)
{
}
-static bool mod_mem_use_vmalloc(enum mod_mem_type type)
-{
- return IS_ENABLED(CONFIG_ARCH_WANTS_MODULES_DATA_IN_VMALLOC) &&
- mod_mem_type_is_core_data(type);
-}
-
static void *module_memory_alloc(unsigned int size, enum mod_mem_type type)
{
- if (mod_mem_use_vmalloc(type))
- return vzalloc(size);
+ if (mod_mem_type_is_data(type))
+ return execmem_data_alloc(size);
return execmem_text_alloc(size);
}
static void module_memory_free(void *ptr, enum mod_mem_type type)
{
- if (mod_mem_use_vmalloc(type))
- vfree(ptr);
- else
- execmem_free(ptr);
+ execmem_free(ptr);
}
static void free_mod_mem(struct module *mod)
diff --git a/mm/execmem.c b/mm/execmem.c
index a67acd75ffef..f7bf496ad4c3 100644
--- a/mm/execmem.c
+++ b/mm/execmem.c
@@ -63,6 +63,20 @@ void *execmem_text_alloc(size_t size)
fallback_start, fallback_end, kasan);
}
+void *execmem_data_alloc(size_t size)
+{
+ unsigned long start = execmem_params.modules.data.start;
+ unsigned long end = execmem_params.modules.data.end;
+ pgprot_t pgprot = execmem_params.modules.data.pgprot;
+ unsigned int align = execmem_params.modules.data.alignment;
+ unsigned long fallback_start = execmem_params.modules.data.fallback_start;
+ unsigned long fallback_end = execmem_params.modules.data.fallback_end;
+ bool kasan = execmem_params.modules.flags & EXECMEM_KASAN_SHADOW;
+
+ return execmem_alloc(size, start, end, align, pgprot,
+ fallback_start, fallback_end, kasan);
+}
+
void execmem_free(void *ptr)
{
/*
@@ -101,6 +115,28 @@ static bool execmem_validate_params(struct execmem_params *p)
return true;
}
+static void execmem_init_missing(struct execmem_params *p)
+{
+ struct execmem_modules_range *m = &p->modules;
+
+ if (!pgprot_val(execmem_params.modules.data.pgprot))
+ execmem_params.modules.data.pgprot = PAGE_KERNEL;
+
+ if (!execmem_params.modules.data.alignment)
+ execmem_params.modules.data.alignment = m->text.alignment;
+
+ if (!execmem_params.modules.data.start) {
+ execmem_params.modules.data.start = m->text.start;
+ execmem_params.modules.data.end = m->text.end;
+ }
+
+ if (!execmem_params.modules.data.fallback_start &&
+ execmem_params.modules.text.fallback_start) {
+ execmem_params.modules.data.fallback_start = m->text.fallback_start;
+ execmem_params.modules.data.fallback_end = m->text.fallback_end;
+ }
+}
+
void __init execmem_init(void)
{
struct execmem_params *p = execmem_arch_params();
@@ -112,6 +148,11 @@ void __init execmem_init(void)
p->modules.text.pgprot = PAGE_KERNEL_EXEC;
p->modules.text.alignment = 1;
+ p->modules.data.start = VMALLOC_START;
+ p->modules.data.end = VMALLOC_END;
+ p->modules.data.pgprot = PAGE_KERNEL;
+ p->modules.data.alignment = 1;
+
return;
}
@@ -119,4 +160,6 @@ void __init execmem_init(void)
return;
execmem_params = *p;
+
+ execmem_init_missing(p);
}
--
2.35.1
next prev parent reply other threads:[~2023-06-16 8:52 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-16 8:50 [PATCH v2 00/12] mm: jit/text allocator Mike Rapoport
2023-06-16 8:50 ` [PATCH v2 01/12] nios2: define virtual address space for modules Mike Rapoport
2023-06-16 16:00 ` Edgecombe, Rick P
2023-06-17 5:52 ` Mike Rapoport
2023-06-16 18:14 ` Song Liu
2023-06-16 8:50 ` [PATCH v2 02/12] mm: introduce execmem_text_alloc() and jit_text_alloc() Mike Rapoport
2023-06-16 16:48 ` Kent Overstreet
2023-06-16 18:18 ` Song Liu
2023-06-17 5:57 ` Mike Rapoport
2023-06-17 20:38 ` Andy Lutomirski
2023-06-18 8:00 ` Mike Rapoport
2023-06-19 17:09 ` Andy Lutomirski
2023-06-19 20:18 ` Nadav Amit
2023-06-20 17:24 ` Andy Lutomirski
2023-06-25 16:14 ` Mike Rapoport
2023-06-25 16:59 ` Andy Lutomirski
2023-06-25 17:42 ` Mike Rapoport
2023-06-25 18:07 ` Kent Overstreet
2023-06-26 6:13 ` Song Liu
2023-06-26 9:54 ` Puranjay Mohan
2023-06-26 12:23 ` Mark Rutland
2023-06-26 12:31 ` Mark Rutland
2023-06-26 17:48 ` Song Liu
2023-07-17 17:23 ` Andy Lutomirski
2023-06-26 13:01 ` Mark Rutland
2023-06-19 11:34 ` Kent Overstreet
2023-06-16 8:50 ` [PATCH v2 03/12] mm/execmem, arch: convert simple overrides of module_alloc to execmem Mike Rapoport
2023-06-16 18:36 ` Song Liu
2023-06-16 8:50 ` [PATCH v2 04/12] mm/execmem, arch: convert remaining " Mike Rapoport
2023-06-16 16:16 ` Edgecombe, Rick P
2023-06-17 6:10 ` Mike Rapoport
2023-06-16 18:53 ` Song Liu
2023-06-17 6:14 ` Mike Rapoport
2023-06-16 8:50 ` [PATCH v2 05/12] modules, execmem: drop module_alloc Mike Rapoport
2023-06-16 18:56 ` Song Liu
2023-06-16 8:50 ` Mike Rapoport [this message]
2023-06-16 16:55 ` [PATCH v2 06/12] mm/execmem: introduce execmem_data_alloc() Edgecombe, Rick P
2023-06-17 6:44 ` Mike Rapoport
2023-06-16 20:01 ` Song Liu
2023-06-17 6:51 ` Mike Rapoport
2023-06-18 22:32 ` Thomas Gleixner
2023-06-18 23:14 ` Kent Overstreet
2023-06-19 0:43 ` Thomas Gleixner
2023-06-19 2:12 ` Kent Overstreet
2023-06-20 14:51 ` Steven Rostedt
2023-06-20 15:32 ` Alexei Starovoitov
2023-06-19 15:23 ` Mike Rapoport
2023-06-16 8:50 ` [PATCH v2 07/12] arm64, execmem: extend execmem_params for generated code definitions Mike Rapoport
2023-06-16 20:05 ` Song Liu
2023-06-17 6:57 ` Mike Rapoport
2023-06-17 15:36 ` Kent Overstreet
2023-06-17 16:38 ` Song Liu
2023-06-17 20:37 ` Kent Overstreet
2023-06-16 8:50 ` [PATCH v2 08/12] riscv: extend execmem_params for kprobes allocations Mike Rapoport
2023-06-16 20:09 ` Song Liu
2023-06-16 8:50 ` [PATCH v2 09/12] powerpc: " Mike Rapoport
2023-06-16 20:09 ` Song Liu
2023-06-16 8:50 ` [PATCH v2 10/12] arch: make execmem setup available regardless of CONFIG_MODULES Mike Rapoport
2023-06-16 20:17 ` Song Liu
2023-06-16 8:50 ` [PATCH v2 11/12] x86/ftrace: enable dynamic ftrace without CONFIG_MODULES Mike Rapoport
2023-06-16 20:18 ` Song Liu
2023-06-16 8:50 ` [PATCH v2 12/12] kprobes: remove dependcy on CONFIG_MODULES Mike Rapoport
2023-06-16 11:44 ` Björn Töpel
2023-06-17 6:52 ` Mike Rapoport
2023-06-16 17:02 ` [PATCH v2 00/12] mm: jit/text allocator Edgecombe, Rick P
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=20230616085038.4121892-7-rppt@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=bpf@vger.kernel.org \
--cc=catalin.marinas@arm.com \
--cc=chenhuacai@kernel.org \
--cc=christophe.leroy@csgroup.eu \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=dinguyen@kernel.org \
--cc=hca@linux.ibm.com \
--cc=kent.overstreet@linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-modules@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=linux-trace-kernel@vger.kernel.org \
--cc=linux@armlinux.org.uk \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=loongarch@lists.linux.dev \
--cc=mark.rutland@arm.com \
--cc=mcgrof@kernel.org \
--cc=mpe@ellerman.id.au \
--cc=nadav.amit@gmail.com \
--cc=naveen.n.rao@linux.ibm.com \
--cc=netdev@vger.kernel.org \
--cc=palmer@dabbelt.com \
--cc=puranjay12@gmail.com \
--cc=rick.p.edgecombe@intel.com \
--cc=rostedt@goodmis.org \
--cc=song@kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=tglx@linutronix.de \
--cc=tsbogend@alpha.franken.de \
--cc=will@kernel.org \
--cc=x86@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: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).