From: Mike Rapoport <rppt@kernel.org>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: linux-kernel@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>,
"Björn Töpel" <bjorn@kernel.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>,
"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: Re: [PATCH v3 08/13] riscv: extend execmem_params for generated code allocations
Date: Sat, 23 Sep 2023 19:23:40 +0300 [thread overview]
Message-ID: <20230923162340.GM3303@kernel.org> (raw)
In-Reply-To: <6d686c54-078d-8d71-d4e2-c754cf92c557@ghiti.fr>
On Fri, Sep 22, 2023 at 12:37:07PM +0200, Alexandre Ghiti wrote:
> Hi Mike,
>
> On 18/09/2023 09:29, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)" <rppt@kernel.org>
> >
> > The memory allocations for kprobes and BPF on RISC-V are not placed in
> > the modules area and these custom allocations are implemented with
> > overrides of alloc_insn_page() and bpf_jit_alloc_exec().
> >
> > Slightly reorder execmem_params initialization to support both 32 and 64
> > bit variants, define EXECMEM_KPROBES and EXECMEM_BPF ranges in
> > riscv::execmem_params and drop overrides of alloc_insn_page() and
> > bpf_jit_alloc_exec().
> >
> > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > ---
> > arch/riscv/kernel/module.c | 21 ++++++++++++++++++++-
> > arch/riscv/kernel/probes/kprobes.c | 10 ----------
> > arch/riscv/net/bpf_jit_core.c | 13 -------------
> > 3 files changed, 20 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
> > index 343a0edfb6dd..31505ecb5c72 100644
> > --- a/arch/riscv/kernel/module.c
> > +++ b/arch/riscv/kernel/module.c
> > @@ -436,20 +436,39 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
> > return 0;
> > }
> > -#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
> > +#ifdef CONFIG_MMU
> > static struct execmem_params execmem_params __ro_after_init = {
> > .ranges = {
> > [EXECMEM_DEFAULT] = {
> > .pgprot = PAGE_KERNEL,
> > .alignment = 1,
> > },
> > + [EXECMEM_KPROBES] = {
> > + .pgprot = PAGE_KERNEL_READ_EXEC,
> > + .alignment = 1,
> > + },
> > + [EXECMEM_BPF] = {
> > + .pgprot = PAGE_KERNEL,
> > + .alignment = 1,
>
>
> Not entirely sure it is the same alignment (sorry did not go through the
> entire series), but if it is, the alignment above ^ is not the same that is
> requested by our current bpf_jit_alloc_exec() implementation which is
> PAGE_SIZE.
This literally translates vmalloc() in alloc_insn_page() to a set of
parameters, so "1" comes from there. And using alignment of 1 with
vmalloc() implicitly sets it to PAGE_SIZE.
> > + },
> > },
> > };
> > struct execmem_params __init *execmem_arch_params(void)
> > {
> > +#ifdef CONFIG_64BIT
> > execmem_params.ranges[EXECMEM_DEFAULT].start = MODULES_VADDR;
> > execmem_params.ranges[EXECMEM_DEFAULT].end = MODULES_END;
> > +#else
> > + execmem_params.ranges[EXECMEM_DEFAULT].start = VMALLOC_START;
> > + execmem_params.ranges[EXECMEM_DEFAULT].end = VMALLOC_END;
> > +#endif
> > +
> > + execmem_params.ranges[EXECMEM_KPROBES].start = VMALLOC_START;
> > + execmem_params.ranges[EXECMEM_KPROBES].end = VMALLOC_END;
> > +
> > + execmem_params.ranges[EXECMEM_BPF].start = BPF_JIT_REGION_START;
> > + execmem_params.ranges[EXECMEM_BPF].end = BPF_JIT_REGION_END;
> > return &execmem_params;
> > }
> > diff --git a/arch/riscv/kernel/probes/kprobes.c b/arch/riscv/kernel/probes/kprobes.c
> > index 2f08c14a933d..e64f2f3064eb 100644
> > --- a/arch/riscv/kernel/probes/kprobes.c
> > +++ b/arch/riscv/kernel/probes/kprobes.c
> > @@ -104,16 +104,6 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
> > return 0;
> > }
> > -#ifdef CONFIG_MMU
> > -void *alloc_insn_page(void)
> > -{
> > - return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END,
> > - GFP_KERNEL, PAGE_KERNEL_READ_EXEC,
> > - VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
> > - __builtin_return_address(0));
> > -}
> > -#endif
> > -
> > /* install breakpoint in text */
> > void __kprobes arch_arm_kprobe(struct kprobe *p)
> > {
> > diff --git a/arch/riscv/net/bpf_jit_core.c b/arch/riscv/net/bpf_jit_core.c
> > index 7b70ccb7fec3..c8a758f0882b 100644
> > --- a/arch/riscv/net/bpf_jit_core.c
> > +++ b/arch/riscv/net/bpf_jit_core.c
> > @@ -218,19 +218,6 @@ u64 bpf_jit_alloc_exec_limit(void)
> > return BPF_JIT_REGION_SIZE;
> > }
> > -void *bpf_jit_alloc_exec(unsigned long size)
> > -{
> > - return __vmalloc_node_range(size, PAGE_SIZE, BPF_JIT_REGION_START,
> > - BPF_JIT_REGION_END, GFP_KERNEL,
> > - PAGE_KERNEL, 0, NUMA_NO_NODE,
> > - __builtin_return_address(0));
> > -}
> > -
> > -void bpf_jit_free_exec(void *addr)
> > -{
> > - return vfree(addr);
> > -}
> > -
> > void *bpf_arch_text_copy(void *dst, void *src, size_t len)
> > {
> > int ret;
>
>
> Otherwise, you can add:
>
> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
>
> Thanks,
>
> Alex
>
>
--
Sincerely yours,
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: linux-kernel@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>,
"Björn Töpel" <bjorn@kernel.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>,
"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: Re: [PATCH v3 08/13] riscv: extend execmem_params for generated code allocations
Date: Sat, 23 Sep 2023 19:23:40 +0300 [thread overview]
Message-ID: <20230923162340.GM3303@kernel.org> (raw)
In-Reply-To: <6d686c54-078d-8d71-d4e2-c754cf92c557@ghiti.fr>
On Fri, Sep 22, 2023 at 12:37:07PM +0200, Alexandre Ghiti wrote:
> Hi Mike,
>
> On 18/09/2023 09:29, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)" <rppt@kernel.org>
> >
> > The memory allocations for kprobes and BPF on RISC-V are not placed in
> > the modules area and these custom allocations are implemented with
> > overrides of alloc_insn_page() and bpf_jit_alloc_exec().
> >
> > Slightly reorder execmem_params initialization to support both 32 and 64
> > bit variants, define EXECMEM_KPROBES and EXECMEM_BPF ranges in
> > riscv::execmem_params and drop overrides of alloc_insn_page() and
> > bpf_jit_alloc_exec().
> >
> > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > ---
> > arch/riscv/kernel/module.c | 21 ++++++++++++++++++++-
> > arch/riscv/kernel/probes/kprobes.c | 10 ----------
> > arch/riscv/net/bpf_jit_core.c | 13 -------------
> > 3 files changed, 20 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
> > index 343a0edfb6dd..31505ecb5c72 100644
> > --- a/arch/riscv/kernel/module.c
> > +++ b/arch/riscv/kernel/module.c
> > @@ -436,20 +436,39 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
> > return 0;
> > }
> > -#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
> > +#ifdef CONFIG_MMU
> > static struct execmem_params execmem_params __ro_after_init = {
> > .ranges = {
> > [EXECMEM_DEFAULT] = {
> > .pgprot = PAGE_KERNEL,
> > .alignment = 1,
> > },
> > + [EXECMEM_KPROBES] = {
> > + .pgprot = PAGE_KERNEL_READ_EXEC,
> > + .alignment = 1,
> > + },
> > + [EXECMEM_BPF] = {
> > + .pgprot = PAGE_KERNEL,
> > + .alignment = 1,
>
>
> Not entirely sure it is the same alignment (sorry did not go through the
> entire series), but if it is, the alignment above ^ is not the same that is
> requested by our current bpf_jit_alloc_exec() implementation which is
> PAGE_SIZE.
This literally translates vmalloc() in alloc_insn_page() to a set of
parameters, so "1" comes from there. And using alignment of 1 with
vmalloc() implicitly sets it to PAGE_SIZE.
> > + },
> > },
> > };
> > struct execmem_params __init *execmem_arch_params(void)
> > {
> > +#ifdef CONFIG_64BIT
> > execmem_params.ranges[EXECMEM_DEFAULT].start = MODULES_VADDR;
> > execmem_params.ranges[EXECMEM_DEFAULT].end = MODULES_END;
> > +#else
> > + execmem_params.ranges[EXECMEM_DEFAULT].start = VMALLOC_START;
> > + execmem_params.ranges[EXECMEM_DEFAULT].end = VMALLOC_END;
> > +#endif
> > +
> > + execmem_params.ranges[EXECMEM_KPROBES].start = VMALLOC_START;
> > + execmem_params.ranges[EXECMEM_KPROBES].end = VMALLOC_END;
> > +
> > + execmem_params.ranges[EXECMEM_BPF].start = BPF_JIT_REGION_START;
> > + execmem_params.ranges[EXECMEM_BPF].end = BPF_JIT_REGION_END;
> > return &execmem_params;
> > }
> > diff --git a/arch/riscv/kernel/probes/kprobes.c b/arch/riscv/kernel/probes/kprobes.c
> > index 2f08c14a933d..e64f2f3064eb 100644
> > --- a/arch/riscv/kernel/probes/kprobes.c
> > +++ b/arch/riscv/kernel/probes/kprobes.c
> > @@ -104,16 +104,6 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
> > return 0;
> > }
> > -#ifdef CONFIG_MMU
> > -void *alloc_insn_page(void)
> > -{
> > - return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END,
> > - GFP_KERNEL, PAGE_KERNEL_READ_EXEC,
> > - VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
> > - __builtin_return_address(0));
> > -}
> > -#endif
> > -
> > /* install breakpoint in text */
> > void __kprobes arch_arm_kprobe(struct kprobe *p)
> > {
> > diff --git a/arch/riscv/net/bpf_jit_core.c b/arch/riscv/net/bpf_jit_core.c
> > index 7b70ccb7fec3..c8a758f0882b 100644
> > --- a/arch/riscv/net/bpf_jit_core.c
> > +++ b/arch/riscv/net/bpf_jit_core.c
> > @@ -218,19 +218,6 @@ u64 bpf_jit_alloc_exec_limit(void)
> > return BPF_JIT_REGION_SIZE;
> > }
> > -void *bpf_jit_alloc_exec(unsigned long size)
> > -{
> > - return __vmalloc_node_range(size, PAGE_SIZE, BPF_JIT_REGION_START,
> > - BPF_JIT_REGION_END, GFP_KERNEL,
> > - PAGE_KERNEL, 0, NUMA_NO_NODE,
> > - __builtin_return_address(0));
> > -}
> > -
> > -void bpf_jit_free_exec(void *addr)
> > -{
> > - return vfree(addr);
> > -}
> > -
> > void *bpf_arch_text_copy(void *dst, void *src, size_t len)
> > {
> > int ret;
>
>
> Otherwise, you can add:
>
> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
>
> Thanks,
>
> Alex
>
>
--
Sincerely yours,
Mike.
_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
x86@kernel.org, "Catalin Marinas" <catalin.marinas@arm.com>,
linux-mips@vger.kernel.org, "Song Liu" <song@kernel.org>,
"Luis Chamberlain" <mcgrof@kernel.org>,
sparclinux@vger.kernel.org, linux-riscv@lists.infradead.org,
"Nadav Amit" <nadav.amit@gmail.com>,
linux-s390@vger.kernel.org, "Helge Deller" <deller@gmx.de>,
"Huacai Chen" <chenhuacai@kernel.org>,
"Russell King" <linux@armlinux.org.uk>,
"Naveen N. Rao" <naveen.n.rao@linux.ibm.com>,
linux-trace-kernel@vger.kernel.org,
"Will Deacon" <will@kernel.org>,
"Heiko Carstens" <hca@linux.ibm.com>,
"Steven Rostedt" <rostedt@goodmis.org>,
loongarch@lists.linux.dev, "Thomas Gleixner" <tglx@linutronix.de>,
bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
"Thomas Bogendoerfer" <tsbogend@alpha.franken.de>,
linux-parisc@vger.kernel.org,
"Puranjay Mohan" <puranjay12@gmail.com>,
linux-mm@kvack.org, netdev@vger.kernel.org,
"Kent Overstreet" <kent.overstreet@linux.dev>,
linux-kernel@vger.kernel.org, "Dinh Nguyen" <dinguyen@kerne>
Subject: Re: [PATCH v3 08/13] riscv: extend execmem_params for generated code allocations
Date: Sat, 23 Sep 2023 19:23:40 +0300 [thread overview]
Message-ID: <20230923162340.GM3303@kernel.org> (raw)
In-Reply-To: <6d686c54-078d-8d71-d4e2-c754cf92c557@ghiti.fr>
On Fri, Sep 22, 2023 at 12:37:07PM +0200, Alexandre Ghiti wrote:
> Hi Mike,
>
> On 18/09/2023 09:29, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)" <rppt@kernel.org>
> >
> > The memory allocations for kprobes and BPF on RISC-V are not placed in
> > the modules area and these custom allocations are implemented with
> > overrides of alloc_insn_page() and bpf_jit_alloc_exec().
> >
> > Slightly reorder execmem_params initialization to support both 32 and 64
> > bit variants, define EXECMEM_KPROBES and EXECMEM_BPF ranges in
> > riscv::execmem_params and drop overrides of alloc_insn_page() and
> > bpf_jit_alloc_exec().
> >
> > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > ---
> > arch/riscv/kernel/module.c | 21 ++++++++++++++++++++-
> > arch/riscv/kernel/probes/kprobes.c | 10 ----------
> > arch/riscv/net/bpf_jit_core.c | 13 -------------
> > 3 files changed, 20 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
> > index 343a0edfb6dd..31505ecb5c72 100644
> > --- a/arch/riscv/kernel/module.c
> > +++ b/arch/riscv/kernel/module.c
> > @@ -436,20 +436,39 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
> > return 0;
> > }
> > -#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
> > +#ifdef CONFIG_MMU
> > static struct execmem_params execmem_params __ro_after_init = {
> > .ranges = {
> > [EXECMEM_DEFAULT] = {
> > .pgprot = PAGE_KERNEL,
> > .alignment = 1,
> > },
> > + [EXECMEM_KPROBES] = {
> > + .pgprot = PAGE_KERNEL_READ_EXEC,
> > + .alignment = 1,
> > + },
> > + [EXECMEM_BPF] = {
> > + .pgprot = PAGE_KERNEL,
> > + .alignment = 1,
>
>
> Not entirely sure it is the same alignment (sorry did not go through the
> entire series), but if it is, the alignment above ^ is not the same that is
> requested by our current bpf_jit_alloc_exec() implementation which is
> PAGE_SIZE.
This literally translates vmalloc() in alloc_insn_page() to a set of
parameters, so "1" comes from there. And using alignment of 1 with
vmalloc() implicitly sets it to PAGE_SIZE.
> > + },
> > },
> > };
> > struct execmem_params __init *execmem_arch_params(void)
> > {
> > +#ifdef CONFIG_64BIT
> > execmem_params.ranges[EXECMEM_DEFAULT].start = MODULES_VADDR;
> > execmem_params.ranges[EXECMEM_DEFAULT].end = MODULES_END;
> > +#else
> > + execmem_params.ranges[EXECMEM_DEFAULT].start = VMALLOC_START;
> > + execmem_params.ranges[EXECMEM_DEFAULT].end = VMALLOC_END;
> > +#endif
> > +
> > + execmem_params.ranges[EXECMEM_KPROBES].start = VMALLOC_START;
> > + execmem_params.ranges[EXECMEM_KPROBES].end = VMALLOC_END;
> > +
> > + execmem_params.ranges[EXECMEM_BPF].start = BPF_JIT_REGION_START;
> > + execmem_params.ranges[EXECMEM_BPF].end = BPF_JIT_REGION_END;
> > return &execmem_params;
> > }
> > diff --git a/arch/riscv/kernel/probes/kprobes.c b/arch/riscv/kernel/probes/kprobes.c
> > index 2f08c14a933d..e64f2f3064eb 100644
> > --- a/arch/riscv/kernel/probes/kprobes.c
> > +++ b/arch/riscv/kernel/probes/kprobes.c
> > @@ -104,16 +104,6 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
> > return 0;
> > }
> > -#ifdef CONFIG_MMU
> > -void *alloc_insn_page(void)
> > -{
> > - return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END,
> > - GFP_KERNEL, PAGE_KERNEL_READ_EXEC,
> > - VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
> > - __builtin_return_address(0));
> > -}
> > -#endif
> > -
> > /* install breakpoint in text */
> > void __kprobes arch_arm_kprobe(struct kprobe *p)
> > {
> > diff --git a/arch/riscv/net/bpf_jit_core.c b/arch/riscv/net/bpf_jit_core.c
> > index 7b70ccb7fec3..c8a758f0882b 100644
> > --- a/arch/riscv/net/bpf_jit_core.c
> > +++ b/arch/riscv/net/bpf_jit_core.c
> > @@ -218,19 +218,6 @@ u64 bpf_jit_alloc_exec_limit(void)
> > return BPF_JIT_REGION_SIZE;
> > }
> > -void *bpf_jit_alloc_exec(unsigned long size)
> > -{
> > - return __vmalloc_node_range(size, PAGE_SIZE, BPF_JIT_REGION_START,
> > - BPF_JIT_REGION_END, GFP_KERNEL,
> > - PAGE_KERNEL, 0, NUMA_NO_NODE,
> > - __builtin_return_address(0));
> > -}
> > -
> > -void bpf_jit_free_exec(void *addr)
> > -{
> > - return vfree(addr);
> > -}
> > -
> > void *bpf_arch_text_copy(void *dst, void *src, size_t len)
> > {
> > int ret;
>
>
> Otherwise, you can add:
>
> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
>
> Thanks,
>
> Alex
>
>
--
Sincerely yours,
Mike.
WARNING: multiple messages have this Message-ID (diff)
From: Mike Rapoport <rppt@kernel.org>
To: Alexandre Ghiti <alex@ghiti.fr>
Cc: linux-kernel@vger.kernel.org,
"Andrew Morton" <akpm@linux-foundation.org>,
"Björn Töpel" <bjorn@kernel.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>,
"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: Re: [PATCH v3 08/13] riscv: extend execmem_params for generated code allocations
Date: Sat, 23 Sep 2023 19:23:40 +0300 [thread overview]
Message-ID: <20230923162340.GM3303@kernel.org> (raw)
In-Reply-To: <6d686c54-078d-8d71-d4e2-c754cf92c557@ghiti.fr>
On Fri, Sep 22, 2023 at 12:37:07PM +0200, Alexandre Ghiti wrote:
> Hi Mike,
>
> On 18/09/2023 09:29, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)" <rppt@kernel.org>
> >
> > The memory allocations for kprobes and BPF on RISC-V are not placed in
> > the modules area and these custom allocations are implemented with
> > overrides of alloc_insn_page() and bpf_jit_alloc_exec().
> >
> > Slightly reorder execmem_params initialization to support both 32 and 64
> > bit variants, define EXECMEM_KPROBES and EXECMEM_BPF ranges in
> > riscv::execmem_params and drop overrides of alloc_insn_page() and
> > bpf_jit_alloc_exec().
> >
> > Signed-off-by: Mike Rapoport (IBM) <rppt@kernel.org>
> > ---
> > arch/riscv/kernel/module.c | 21 ++++++++++++++++++++-
> > arch/riscv/kernel/probes/kprobes.c | 10 ----------
> > arch/riscv/net/bpf_jit_core.c | 13 -------------
> > 3 files changed, 20 insertions(+), 24 deletions(-)
> >
> > diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
> > index 343a0edfb6dd..31505ecb5c72 100644
> > --- a/arch/riscv/kernel/module.c
> > +++ b/arch/riscv/kernel/module.c
> > @@ -436,20 +436,39 @@ int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
> > return 0;
> > }
> > -#if defined(CONFIG_MMU) && defined(CONFIG_64BIT)
> > +#ifdef CONFIG_MMU
> > static struct execmem_params execmem_params __ro_after_init = {
> > .ranges = {
> > [EXECMEM_DEFAULT] = {
> > .pgprot = PAGE_KERNEL,
> > .alignment = 1,
> > },
> > + [EXECMEM_KPROBES] = {
> > + .pgprot = PAGE_KERNEL_READ_EXEC,
> > + .alignment = 1,
> > + },
> > + [EXECMEM_BPF] = {
> > + .pgprot = PAGE_KERNEL,
> > + .alignment = 1,
>
>
> Not entirely sure it is the same alignment (sorry did not go through the
> entire series), but if it is, the alignment above ^ is not the same that is
> requested by our current bpf_jit_alloc_exec() implementation which is
> PAGE_SIZE.
This literally translates vmalloc() in alloc_insn_page() to a set of
parameters, so "1" comes from there. And using alignment of 1 with
vmalloc() implicitly sets it to PAGE_SIZE.
> > + },
> > },
> > };
> > struct execmem_params __init *execmem_arch_params(void)
> > {
> > +#ifdef CONFIG_64BIT
> > execmem_params.ranges[EXECMEM_DEFAULT].start = MODULES_VADDR;
> > execmem_params.ranges[EXECMEM_DEFAULT].end = MODULES_END;
> > +#else
> > + execmem_params.ranges[EXECMEM_DEFAULT].start = VMALLOC_START;
> > + execmem_params.ranges[EXECMEM_DEFAULT].end = VMALLOC_END;
> > +#endif
> > +
> > + execmem_params.ranges[EXECMEM_KPROBES].start = VMALLOC_START;
> > + execmem_params.ranges[EXECMEM_KPROBES].end = VMALLOC_END;
> > +
> > + execmem_params.ranges[EXECMEM_BPF].start = BPF_JIT_REGION_START;
> > + execmem_params.ranges[EXECMEM_BPF].end = BPF_JIT_REGION_END;
> > return &execmem_params;
> > }
> > diff --git a/arch/riscv/kernel/probes/kprobes.c b/arch/riscv/kernel/probes/kprobes.c
> > index 2f08c14a933d..e64f2f3064eb 100644
> > --- a/arch/riscv/kernel/probes/kprobes.c
> > +++ b/arch/riscv/kernel/probes/kprobes.c
> > @@ -104,16 +104,6 @@ int __kprobes arch_prepare_kprobe(struct kprobe *p)
> > return 0;
> > }
> > -#ifdef CONFIG_MMU
> > -void *alloc_insn_page(void)
> > -{
> > - return __vmalloc_node_range(PAGE_SIZE, 1, VMALLOC_START, VMALLOC_END,
> > - GFP_KERNEL, PAGE_KERNEL_READ_EXEC,
> > - VM_FLUSH_RESET_PERMS, NUMA_NO_NODE,
> > - __builtin_return_address(0));
> > -}
> > -#endif
> > -
> > /* install breakpoint in text */
> > void __kprobes arch_arm_kprobe(struct kprobe *p)
> > {
> > diff --git a/arch/riscv/net/bpf_jit_core.c b/arch/riscv/net/bpf_jit_core.c
> > index 7b70ccb7fec3..c8a758f0882b 100644
> > --- a/arch/riscv/net/bpf_jit_core.c
> > +++ b/arch/riscv/net/bpf_jit_core.c
> > @@ -218,19 +218,6 @@ u64 bpf_jit_alloc_exec_limit(void)
> > return BPF_JIT_REGION_SIZE;
> > }
> > -void *bpf_jit_alloc_exec(unsigned long size)
> > -{
> > - return __vmalloc_node_range(size, PAGE_SIZE, BPF_JIT_REGION_START,
> > - BPF_JIT_REGION_END, GFP_KERNEL,
> > - PAGE_KERNEL, 0, NUMA_NO_NODE,
> > - __builtin_return_address(0));
> > -}
> > -
> > -void bpf_jit_free_exec(void *addr)
> > -{
> > - return vfree(addr);
> > -}
> > -
> > void *bpf_arch_text_copy(void *dst, void *src, size_t len)
> > {
> > int ret;
>
>
> Otherwise, you can add:
>
> Reviewed-by: Alexandre Ghiti <alexghiti@rivosinc.com>
>
> Thanks,
>
> Alex
>
>
--
Sincerely yours,
Mike.
_______________________________________________
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-09-23 16:24 UTC|newest]
Thread overview: 196+ 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 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` 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 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 02/13] mm: introduce execmem_text_alloc() and execmem_free() Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-21 22:10 ` Song Liu
2023-09-21 22:10 ` Song Liu
2023-09-21 22:10 ` Song Liu
2023-09-21 22:10 ` Song Liu
2023-09-23 15:42 ` Mike Rapoport
2023-09-23 15:42 ` Mike Rapoport
2023-09-23 15:42 ` Mike Rapoport
2023-09-23 15:42 ` Mike Rapoport
2023-09-21 22:14 ` Song Liu
2023-09-21 22:14 ` Song Liu
2023-09-21 22:14 ` Song Liu
2023-09-21 22:14 ` Song Liu
2023-09-23 15:40 ` Mike Rapoport
2023-09-23 15:40 ` Mike Rapoport
2023-09-23 15:40 ` Mike Rapoport
2023-09-23 15:40 ` Mike Rapoport
2023-09-21 22:34 ` Song Liu
2023-09-21 22:34 ` Song Liu
2023-09-21 22:34 ` Song Liu
2023-09-21 22:34 ` Song Liu
2023-09-23 15:38 ` Mike Rapoport
2023-09-23 15:38 ` Mike Rapoport
2023-09-23 15:38 ` Mike Rapoport
2023-09-23 15:38 ` Mike Rapoport
2023-09-23 22:36 ` Song Liu
2023-09-23 22:36 ` Song Liu
2023-09-23 22:36 ` Song Liu
2023-09-23 22:36 ` Song Liu
2023-09-26 8:04 ` Mike Rapoport
2023-09-26 8:04 ` Mike Rapoport
2023-09-26 8:04 ` Mike Rapoport
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-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-10-04 0:29 ` Edgecombe, Rick P
2023-10-04 0:29 ` Edgecombe, Rick P
2023-10-04 0:29 ` Edgecombe, Rick P
2023-10-04 0:29 ` Edgecombe, Rick P
2023-10-04 15:39 ` Edgecombe, Rick P
2023-10-04 15:39 ` Edgecombe, Rick P
2023-10-04 15:39 ` Edgecombe, Rick P
2023-10-04 15:39 ` Edgecombe, Rick P
2023-10-05 5:26 ` Mike Rapoport
2023-10-05 5:26 ` Mike Rapoport
2023-10-05 5:26 ` Mike Rapoport
2023-10-05 5:26 ` Mike Rapoport
2023-10-05 18:09 ` Edgecombe, Rick P
2023-10-05 18:09 ` Edgecombe, Rick P
2023-10-05 18:09 ` Edgecombe, Rick P
2023-10-05 18:09 ` Edgecombe, Rick P
2023-10-26 8:40 ` Mike Rapoport
2023-10-26 8:40 ` Mike Rapoport
2023-10-26 8:40 ` Mike Rapoport
2023-10-26 8:40 ` Mike Rapoport
2023-10-05 18:11 ` Edgecombe, Rick P
2023-10-05 18:11 ` Edgecombe, Rick P
2023-10-05 18:11 ` Edgecombe, Rick P
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-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-10-04 0:29 ` Edgecombe, Rick P
2023-10-04 0:29 ` Edgecombe, Rick P
2023-10-04 0:29 ` Edgecombe, Rick P
2023-10-04 0:29 ` Edgecombe, Rick P
2023-10-05 5:28 ` Mike Rapoport
2023-10-05 5:28 ` Mike Rapoport
2023-10-05 5:28 ` Mike Rapoport
2023-10-05 5:28 ` Mike Rapoport
2023-10-23 17:14 ` Will Deacon
2023-10-23 17:14 ` Will Deacon
2023-10-23 17:14 ` Will Deacon
2023-10-23 17:14 ` Will Deacon
2023-10-26 8:58 ` Mike Rapoport
2023-10-26 8:58 ` Mike Rapoport
2023-10-26 8:58 ` Mike Rapoport
2023-10-26 8:58 ` Mike Rapoport
2023-10-26 10:24 ` Will Deacon
2023-10-26 10:24 ` Will Deacon
2023-10-26 10:24 ` Will Deacon
2023-10-26 10:24 ` Will Deacon
2023-10-30 7:00 ` Mike Rapoport
2023-10-30 7:00 ` Mike Rapoport
2023-10-30 7:00 ` Mike Rapoport
2023-10-30 7:00 ` Mike Rapoport
2023-11-07 10:44 ` Will Deacon
2023-11-07 10:44 ` Will Deacon
2023-11-07 10:44 ` Will Deacon
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 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 06/13] mm/execmem: introduce execmem_data_alloc() Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-21 22:52 ` Song Liu
2023-09-21 22:52 ` Song Liu
2023-09-21 22:52 ` Song Liu
2023-09-21 22:52 ` Song Liu
2023-09-22 7:16 ` Christophe Leroy
2023-09-22 7:16 ` Christophe Leroy
2023-09-22 7:16 ` Christophe Leroy
2023-09-22 7:16 ` Christophe Leroy
2023-09-22 8:55 ` Song Liu
2023-09-22 8:55 ` Song Liu
2023-09-22 8:55 ` Song Liu
2023-09-22 8:55 ` Song Liu
2023-09-22 10:13 ` Christophe Leroy
2023-09-22 10:13 ` Christophe Leroy
2023-09-22 10:13 ` Christophe Leroy
2023-09-22 10:13 ` Christophe Leroy
2023-09-23 16:20 ` Mike Rapoport
2023-09-23 16:20 ` Mike Rapoport
2023-09-23 16:20 ` Mike Rapoport
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-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-10-23 17:21 ` Will Deacon
2023-10-23 17:21 ` Will Deacon
2023-10-23 17:21 ` Will Deacon
2023-10-23 17:21 ` Will Deacon
2023-09-18 7:29 ` [PATCH v3 08/13] riscv: " Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-22 10:37 ` Alexandre Ghiti
2023-09-22 10:37 ` Alexandre Ghiti
2023-09-22 10:37 ` Alexandre Ghiti
2023-09-22 10:37 ` Alexandre Ghiti
2023-09-23 16:23 ` Mike Rapoport [this message]
2023-09-23 16:23 ` Mike Rapoport
2023-09-23 16:23 ` Mike Rapoport
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-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-21 22:30 ` Song Liu
2023-09-21 22:30 ` Song Liu
2023-09-21 22:30 ` Song Liu
2023-09-21 22:30 ` Song Liu
2023-09-23 16:25 ` Mike Rapoport
2023-09-23 16:25 ` Mike Rapoport
2023-09-23 16:25 ` Mike Rapoport
2023-09-23 16:25 ` Mike Rapoport
2023-09-22 10:32 ` Christophe Leroy
2023-09-22 10:32 ` Christophe Leroy
2023-09-22 10:32 ` Christophe Leroy
2023-09-22 10:32 ` Christophe Leroy
2023-09-23 16:27 ` Mike Rapoport
2023-09-23 16:27 ` Mike Rapoport
2023-09-23 16:27 ` Mike Rapoport
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-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-26 7:33 ` Arnd Bergmann
2023-09-26 7:33 ` Arnd Bergmann
2023-09-26 7:33 ` Arnd Bergmann
2023-09-26 7:33 ` Arnd Bergmann
2023-09-26 8:32 ` Mike Rapoport
2023-09-26 8:32 ` Mike Rapoport
2023-09-26 8:32 ` Mike Rapoport
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 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 12/13] kprobes: remove dependency on CONFIG_MODULES Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` [PATCH v3 13/13] bpf: remove CONFIG_BPF_JIT dependency on CONFIG_MODULES of Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` Mike Rapoport
2023-09-18 7:29 ` 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=20230923162340.GM3303@kernel.org \
--to=rppt@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alex@ghiti.fr \
--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=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 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.