From: "Edgecombe, Rick P" <rick.p.edgecombe@intel.com>
To: "rppt@kernel.org" <rppt@kernel.org>
Cc: "tglx@linutronix.de" <tglx@linutronix.de>,
"mcgrof@kernel.org" <mcgrof@kernel.org>,
"deller@gmx.de" <deller@gmx.de>,
"bjorn@kernel.org" <bjorn@kernel.org>,
"davem@davemloft.net" <davem@davemloft.net>,
"nadav.amit@gmail.com" <nadav.amit@gmail.com>,
"linux@armlinux.org.uk" <linux@armlinux.org.uk>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>,
"linux-mips@vger.kernel.org" <linux-mips@vger.kernel.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"hca@linux.ibm.com" <hca@linux.ibm.com>,
"catalin.marinas@arm.com" <catalin.marinas@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kent.overstreet@linux.dev" <kent.overstreet@linux.dev>,
"puranjay12@gmail.com" <puranjay12@gmail.com>,
"linux-s390@vger.kernel.org" <linux-s390@vger.kernel.org>,
"palmer@dabbelt.com" <palmer@dabbelt.com>,
"chenhuacai@kernel.org" <chenhuacai@kernel.org>,
"tsbogend@alpha.franken.de" <tsbogend@alpha.franken.de>,
"x86@kernel.org" <x86@kernel.org>,
"mark.rutland@arm.com" <mark.rutland@arm.com>,
"linux-parisc@vger.kernel.org" <linux-parisc@vger.kernel.org>,
"linux-trace-kernel@vger.kernel.org"
<linux-trace-kernel@vger.kernel.org>,
"mpe@ellerman.id.au" <mpe@ellerman.id.au>,
"christophe.leroy@csgroup.eu" <christophe.leroy@csgroup.eu>,
"linux-riscv@lists.infradead.org"
<linux-riscv@lists.infradead.org>,
"rostedt@goodmis.org" <rostedt@goodmis.org>,
"will@kernel.org" <will@kernel.org>,
"dinguyen@kernel.org" <dinguyen@kernel.org>,
"naveen.n.rao@linux.ibm.com" <naveen.n.rao@linux.ibm.com>,
"sparclinux@vger.kernel.org" <sparclinux@vger.kernel.org>,
"linux-modules@vger.kernel.org" <linux-modules@vger.kernel.org>,
"bpf@vger.kernel.org" <bpf@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
"song@kernel.org" <song@kernel.org>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"loongarch@lists.linux.dev" <loongarch@lists.linux.dev>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>
Subject: Re: [PATCH v3 03/13] mm/execmem, arch: convert simple overrides of module_alloc to execmem
Date: Thu, 5 Oct 2023 18:09:07 +0000 [thread overview]
Message-ID: <b26d0a201bf631831a956450ebbccc3c16521133.camel@intel.com> (raw)
In-Reply-To: <20231005052622.GD3303@kernel.org>
On Thu, 2023-10-05 at 08:26 +0300, Mike Rapoport wrote:
> On Wed, Oct 04, 2023 at 03:39:26PM +0000, Edgecombe, Rick P wrote:
> > On Tue, 2023-10-03 at 17:29 -0700, Rick Edgecombe wrote:
> > > It seems a bit weird to copy all of this. Is it trying to be
> > > faster
> > > or
> > > something?
> > >
> > > Couldn't it just check r->start in execmem_text/data_alloc() path
> > > and
> > > switch to EXECMEM_DEFAULT if needed then? The
> > > execmem_range_is_data()
> > > part that comes later could be added to the logic there too. So
> > > this
> > > seems like unnecessary complexity to me or I don't see the
> > > reason.
> >
> > I guess this is a bad idea because if you have the full size array
> > sitting around anyway you might as well use it and reduce the
> > exec_mem_alloc() logic.
>
> That's was the idea, indeed. :)
>
> > Just looking at it from the x86 side (and
> > similar) though, where there is actually only one execmem_range and
> > it
> > building this whole array with identical data and it seems weird.
>
> Right, most architectures have only one range, but to support all
> variants
> that we have, execmem has to maintain the whole array.
What about just having an index into a smaller set of ranges. The
module area and the extra JIT area. So ->ranges can be size 3
(statically allocated in the arch code) for three areas and then the
index array can be size EXECMEM_TYPE_MAX. The default 0 value of the
indexing array will point to the default area and any special areas can
be set in the index point to the desired range.
Looking at how it would do for x86 and arm64, it looks maybe a bit
better to me. A little bit less code and memory usage, and a bit easier
to trace the configuration through to the final state (IMO). What do
you think? Very rough, on top of this series, below.
As I was playing around with this, I was also wondering why it needs
two copies of struct execmem_params: one returned from the arch code
and one in exec mem. And why the temporary arch copy is ro_after_init,
but the final execmem.c copy is not ro_after_init?
arch/arm64/mm/init.c | 67 ++++++++++++++++++++++++++++++++++++++---
--------------------------
arch/x86/mm/init.c | 24 +++++++++++++-----------
include/linux/execmem.h | 5 +++--
mm/execmem.c | 61 ++++++++++++++++-------------------------
--------------------
4 files changed, 70 insertions(+), 87 deletions(-)
diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
index 9b7716b4d84c..7df119101f20 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -633,49 +633,58 @@ static int __init module_init_limits(void)
return 0;
}
-static struct execmem_params execmem_params __ro_after_init = {
- .ranges = {
- [EXECMEM_DEFAULT] = {
- .flags = EXECMEM_KASAN_SHADOW,
- .alignment = MODULE_ALIGN,
- },
- [EXECMEM_KPROBES] = {
- .start = VMALLOC_START,
- .end = VMALLOC_END,
- .alignment = 1,
- },
- [EXECMEM_BPF] = {
- .start = VMALLOC_START,
- .end = VMALLOC_END,
- .alignment = 1,
- },
+static struct execmem_range[2] ranges __ro_after_init = {
+ /* Module area */
+ [0] = {
+ .flags = EXECMEM_KASAN_SHADOW,
+ .alignment = MODULE_ALIGN,
+ },
+ /* Kprobes area */
+ [1] = {
+ .start = VMALLOC_START,
+ .end = VMALLOC_END,
+ .alignment = 1,
+ },
+ /* BPF area */
+ [2] = {
+ .start = VMALLOC_START,
+ .end = VMALLOC_END,
+ .alignment = 1,
},
};
-struct execmem_params __init *execmem_arch_params(void)
+void __init execmem_arch_params(struct execmem_params *p)
{
- struct execmem_range *r =
&execmem_params.ranges[EXECMEM_DEFAULT];
+ struct execmem_range *default;
+ struct execmem_range *jit;
+
+ p->ranges = &ranges;
module_init_limits();
- r->pgprot = PAGE_KERNEL;
-
+ /* Default area */
+ default = &ranges[0];
+ default->pgprot = PAGE_KERNEL;
if (module_direct_base) {
- r->start = module_direct_base;
- r->end = module_direct_base + SZ_128M;
+ default->start = module_direct_base;
+ default->end = module_direct_base + SZ_128M;
if (module_plt_base) {
- r->fallback_start = module_plt_base;
- r->fallback_end = module_plt_base + SZ_2G;
+ default->fallback_start = module_plt_base;
+ default->fallback_end = module_plt_base +
SZ_2G;
}
} else if (module_plt_base) {
- r->start = module_plt_base;
- r->end = module_plt_base + SZ_2G;
+ default->start = module_plt_base;
+ default->end = module_plt_base + SZ_2G;
}
- execmem_params.ranges[EXECMEM_KPROBES].pgprot =
PAGE_KERNEL_ROX;
- execmem_params.ranges[EXECMEM_BPF].pgprot = PAGE_KERNEL;
+ /* Jit area */
+ ranges[1].pgprot = PAGE_KERNEL_ROX;
+ p->defaults[EXECMEM_KPROBES] = 1;
+
- return &execmem_params;
+ /* BPF Area */
+ ranges[2].pgprot = PAGE_KERNEL;
+ p->defaults[EXECMEM_BPF] = 2;
}
#endif
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index 022af7ab50f9..7397472ffc39 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -1102,16 +1102,15 @@ unsigned long arch_max_swapfile_size(void)
#endif
#ifdef CONFIG_EXECMEM
-static struct execmem_params execmem_params __ro_after_init = {
- .ranges = {
- [EXECMEM_DEFAULT] = {
- .flags = EXECMEM_KASAN_SHADOW,
- .alignment = MODULE_ALIGN,
- },
+static struct execmem_range ranges[1] __ro_after_init = {
+ /* Module area */
+ [0] = {
+ .flags = EXECMEM_KASAN_SHADOW,
+ .alignment = MODULE_ALIGN,
},
};
-struct execmem_params __init *execmem_arch_params(void)
+void __init execmem_arch_params(struct execmem_params *p)
{
unsigned long module_load_offset = 0;
unsigned long start;
@@ -1121,10 +1120,13 @@ struct execmem_params __init
*execmem_arch_params(void)
get_random_u32_inclusive(1, 1024) * PAGE_SIZE;
start = MODULES_VADDR + module_load_offset;
- execmem_params.ranges[EXECMEM_DEFAULT].start = start;
- execmem_params.ranges[EXECMEM_DEFAULT].end = MODULES_END;
- execmem_params.ranges[EXECMEM_DEFAULT].pgprot = PAGE_KERNEL;
+ p->ranges = ranges;
- return &execmem_params;
+ /* Module area */
+ p->ranges[0].start = start;
+ p->ranges[0].end = MODULES_END;
+ p->ranges[0].pgprot = PAGE_KERNEL;
+ p->ranges[0].flags = EXECMEM_KASAN_SHADOW;
+ p->ranges[0].alignment = MODULE_ALIGN;
}
#endif /* CONFIG_EXECMEM */
diff --git a/include/linux/execmem.h b/include/linux/execmem.h
index 09d45ac786e9..702435443d87 100644
--- a/include/linux/execmem.h
+++ b/include/linux/execmem.h
@@ -77,7 +77,8 @@ struct execmem_range {
* each type of executable memory allocations
*/
struct execmem_params {
- struct execmem_range ranges[EXECMEM_TYPE_MAX];
+ int areas[EXECMEM_TYPE_MAX];
+ struct execmem_range *ranges;
};
/**
@@ -92,7 +93,7 @@ struct execmem_params {
* Return: a structure defining architecture parameters and
restrictions
* for allocations of executable memory
*/
-struct execmem_params *execmem_arch_params(void);
+void execmem_arch_params(struct execmem_params *p);
/**
* execmem_text_alloc - allocate executable memory
diff --git a/mm/execmem.c b/mm/execmem.c
index aeff85261360..dfdec8c2b074 100644
--- a/mm/execmem.c
+++ b/mm/execmem.c
@@ -6,15 +6,15 @@
#include <linux/moduleloader.h>
static struct execmem_params execmem_params;
+static struct execmem_range default_range;
-static void *execmem_alloc(size_t size, struct execmem_range *range)
+static void *execmem_alloc(size_t size, struct execmem_range *range,
pgprot_t pgprot)
{
unsigned long start = range->start;
unsigned long end = range->end;
unsigned long fallback_start = range->fallback_start;
unsigned long fallback_end = range->fallback_end;
unsigned int align = range->alignment;
- pgprot_t pgprot = range->pgprot;
bool kasan = range->flags & EXECMEM_KASAN_SHADOW;
unsigned long vm_flags = VM_FLUSH_RESET_PERMS;
bool fallback = !!fallback_start;
@@ -60,14 +60,18 @@ static inline bool execmem_range_is_data(enum
execmem_type type)
void *execmem_text_alloc(enum execmem_type type, size_t size)
{
- return execmem_alloc(size, &execmem_params.ranges[type]);
+ struct execmem_range *range =
&execmem_params.ranges[execmem_params.areas[type]];
+
+ return execmem_alloc(size, range, range->pgprot);
}
void *execmem_data_alloc(enum execmem_type type, size_t size)
{
+ struct execmem_range *range =
&execmem_params.ranges[execmem_params.areas[type]];
+
WARN_ON_ONCE(!execmem_range_is_data(type));
- return execmem_alloc(size, &execmem_params.ranges[type]);
+ return execmem_alloc(size, range, PAGE_KERNEL);
}
void execmem_free(void *ptr)
@@ -80,9 +84,13 @@ void execmem_free(void *ptr)
vfree(ptr);
}
-struct execmem_params * __weak execmem_arch_params(void)
+void __weak execmem_arch_params(struct execmem_params *p)
{
- return NULL;
+ p->ranges = default_range;
+ p->ranges[EXECMEM_DEFAULT].start = VMALLOC_START;
+ p->ranges[EXECMEM_DEFAULT].end = VMALLOC_END;
+ p->ranges[EXECMEM_DEFAULT].pgprot = PAGE_KERNEL_EXEC;
+ p->ranges[EXECMEM_DEFAULT].alignment = 1;
}
static bool execmem_validate_params(struct execmem_params *p)
@@ -97,46 +105,9 @@ static bool execmem_validate_params(struct
execmem_params *p)
return true;
}
-static void execmem_init_missing(struct execmem_params *p)
-{
- struct execmem_range *default_range = &p-
>ranges[EXECMEM_DEFAULT];
-
- for (int i = EXECMEM_DEFAULT + 1; i < EXECMEM_TYPE_MAX; i++) {
- struct execmem_range *r = &p->ranges[i];
-
- if (!r->start) {
- if (execmem_range_is_data(i))
- r->pgprot = PAGE_KERNEL;
- else
- r->pgprot = default_range->pgprot;
- r->alignment = default_range->alignment;
- r->start = default_range->start;
- r->end = default_range->end;
- r->flags = default_range->flags;
- r->fallback_start = default_range-
>fallback_start;
- r->fallback_end = default_range->fallback_end;
- }
- }
-}
-
void __init execmem_init(void)
{
- struct execmem_params *p = execmem_arch_params();
+ execmem_arch_params(&execmem_params);
- if (!p) {
- p = &execmem_params;
- p->ranges[EXECMEM_DEFAULT].start = VMALLOC_START;
- p->ranges[EXECMEM_DEFAULT].end = VMALLOC_END;
- p->ranges[EXECMEM_DEFAULT].pgprot = PAGE_KERNEL_EXEC;
- p->ranges[EXECMEM_DEFAULT].alignment = 1;
-
- return;
- }
-
- if (!execmem_validate_params(p))
- return;
-
- execmem_init_missing(p);
-
- execmem_params = *p;
+ execmem_validate_params(&execmem_params);
}
_______________________________________________
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:[~2023-10-05 18:09 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-18 7:29 [PATCH v3 00/13] mm: jit/text allocator Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 01/13] nios2: define virtual address space for modules Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 02/13] mm: introduce execmem_text_alloc() and execmem_free() Mike Rapoport
2023-09-21 22:10 ` Song Liu
2023-09-23 15:42 ` Mike Rapoport
2023-09-21 22:14 ` Song Liu
2023-09-23 15:40 ` Mike Rapoport
2023-09-21 22:34 ` Song Liu
2023-09-23 15:38 ` Mike Rapoport
2023-09-23 22:36 ` Song Liu
2023-09-26 8:04 ` Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 03/13] mm/execmem, arch: convert simple overrides of module_alloc to execmem Mike Rapoport
2023-10-04 0:29 ` Edgecombe, Rick P
2023-10-04 15:39 ` Edgecombe, Rick P
2023-10-05 5:26 ` Mike Rapoport
2023-10-05 18:09 ` Edgecombe, Rick P [this message]
2023-10-26 8:40 ` Mike Rapoport
2023-10-05 18:11 ` Edgecombe, Rick P
2023-09-18 7:29 ` [PATCH v3 04/13] mm/execmem, arch: convert remaining " Mike Rapoport
2023-10-04 0:29 ` Edgecombe, Rick P
2023-10-05 5:28 ` Mike Rapoport
2023-10-23 17:14 ` Will Deacon
2023-10-26 8:58 ` Mike Rapoport
2023-10-26 10:24 ` Will Deacon
2023-10-30 7:00 ` Mike Rapoport
2023-11-07 10:44 ` Will Deacon
2023-09-18 7:29 ` [PATCH v3 05/13] modules, execmem: drop module_alloc Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 06/13] mm/execmem: introduce execmem_data_alloc() Mike Rapoport
2023-09-21 22:52 ` Song Liu
2023-09-22 7:16 ` Christophe Leroy
2023-09-22 8:55 ` Song Liu
2023-09-22 10:13 ` Christophe Leroy
2023-09-23 16:20 ` Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 07/13] arm64, execmem: extend execmem_params for generated code allocations Mike Rapoport
2023-10-23 17:21 ` Will Deacon
2023-09-18 7:29 ` [PATCH v3 08/13] riscv: " Mike Rapoport
2023-09-22 10:37 ` Alexandre Ghiti
2023-09-23 16:23 ` Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 09/13] powerpc: extend execmem_params for kprobes allocations Mike Rapoport
2023-09-21 22:30 ` Song Liu
2023-09-23 16:25 ` Mike Rapoport
2023-09-22 10:32 ` Christophe Leroy
2023-09-23 16:27 ` Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 10/13] arch: make execmem setup available regardless of CONFIG_MODULES Mike Rapoport
2023-09-26 7:33 ` Arnd Bergmann
2023-09-26 8:32 ` Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 11/13] x86/ftrace: enable dynamic ftrace without CONFIG_MODULES Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 12/13] kprobes: remove dependency on CONFIG_MODULES Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 13/13] bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES of Mike Rapoport
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=b26d0a201bf631831a956450ebbccc3c16521133.camel@intel.com \
--to=rick.p.edgecombe@intel.com \
--cc=akpm@linux-foundation.org \
--cc=bjorn@kernel.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=rostedt@goodmis.org \
--cc=rppt@kernel.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).