Thread (65 messages) 65 messages, 12 authors, 2023-07-17

Re: [PATCH v2 07/12] arm64, execmem: extend execmem_params for generated code definitions

From: Mike Rapoport <rppt@kernel.org>
Date: 2023-06-17 06:58:56
Also in: bpf, linux-arm-kernel, linux-mips, linux-mm, linux-riscv, linux-s390, linux-trace-kernel, linuxppc-dev, lkml, loongarch, netdev, sparclinux

On Fri, Jun 16, 2023 at 01:05:29PM -0700, Song Liu wrote:
On Fri, Jun 16, 2023 at 1:52 AM Mike Rapoport [off-list ref] wrote:
quoted
From: "Mike Rapoport (IBM)" <rppt@kernel.org>

The memory allocations for kprobes on arm64 can be placed anywhere in
vmalloc address space and currently this is implemented with an override
of alloc_insn_page() in arm64.

Extend execmem_params with a range for generated code allocations and
make kprobes on arm64 use this extension rather than override
alloc_insn_page().

Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
---
 arch/arm64/kernel/module.c         |  9 +++++++++
 arch/arm64/kernel/probes/kprobes.c |  7 -------
 include/linux/execmem.h            | 11 +++++++++++
 mm/execmem.c                       | 14 +++++++++++++-
 4 files changed, 33 insertions(+), 8 deletions(-)
diff --git a/arch/arm64/kernel/module.c b/arch/arm64/kernel/module.c
index c3d999f3a3dd..52b09626bc0f 100644
--- a/arch/arm64/kernel/module.c
+++ b/arch/arm64/kernel/module.c
@@ -30,6 +30,13 @@ static struct execmem_params execmem_params = {
                        .alignment = MODULE_ALIGN,
                },
        },
+       .jit = {
+               .text = {
+                       .start = VMALLOC_START,
+                       .end = VMALLOC_END,
+                       .alignment = 1,
+               },
+       },
 };
This is growing fast. :) We have 3 now: text, data, jit. And it will be
5 when we split data into rw data, ro data, ro after init data. I wonder
whether we should still do some type enum here. But we can revisit
this topic later.
I don't think we'd need 5. Four at most :)

I don't know yet what would be the best way to differentiate RW and RO
data, but ro_after_init surely won't need a new type. It either will be
allocated as RW and then the caller will have to set it RO after
initialization is done, or it will be allocated as RO and the caller will
have to do something like text_poke to update it.
 
Other than that

Acked-by: Song Liu <song@kernel.org>
-- 
Sincerely yours,
Mike.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help