From: "Mike Rapoport (IBM)"
In order to support ROX allocations for module text, it is necessary to
handle modifications to the code, such as relocations and alternatives
patching, without write access to that memory.
One option is to use text patching, but this would make modu
From: "Mike Rapoport (IBM)"
vmalloc allocations with VM_ALLOW_HUGE_VMAP that do not explictly
specify node ID will use huge pages only if size_per_node is larger than
PMD_SIZE.
Still the actual allocated memory is not distributed between nodes and
there is no advantage in suc
From: "Mike Rapoport (IBM)"
Several architectures support text patching, but they name the header
files that declare patching functions differently.
Make all such headers consistently named text-patching.h and add an empty
header in asm-generic for architectures that do not su
From: "Mike Rapoport (IBM)"
Hi,
These patches add support for using large ROX pages for allocations of
executable memory on x86.
They address Andy's comments [1] about having executable mappings for code
that was not completely formed.
The approach taken is to allocate ROX me
From: "Mike Rapoport (IBM)"
BPF just-in-time compiler depended on CONFIG_MODULES because it used
module_alloc() to allocate memory for the generated code.
Since code allocations are now implemented with execmem, drop dependency of
CONFIG_BPF_JIT on CONFIG_MODULES and make
From: "Mike Rapoport (IBM)"
kprobes depended on CONFIG_MODULES because it has to allocate memory for
code.
Since code allocations are now implemented with execmem, kprobes can be
enabled in non-modular kernels.
Add #ifdef CONFIG_MODULE guards for the code dealing with kprobes insi
From: "Mike Rapoport (IBM)"
There are places where CONFIG_MODULES guards the code that depends on
memory allocation being done with module_alloc().
Replace CONFIG_MODULES with CONFIG_EXECMEM in such places.
Signed-off-by: Mike Rapoport (IBM)
---
arch/powerpc/Kconfig
From: "Mike Rapoport (IBM)"
Dynamic ftrace must allocate memory for code and this was impossible
without CONFIG_MODULES.
With execmem separated from the modules code, execmem_text_alloc() is
available regardless of CONFIG_MODULES.
Remove dependency of dynamic ftrace on CONFIG_MODULE
From: "Mike Rapoport (IBM)"
execmem does not depend on modules, on the contrary modules use
execmem.
To make execmem available when CONFIG_MODULES=n, for instance for
kprobes, split execmem_params initialization out from
arch/*/kernel/module.c and compile it when CONFIG_EXECMEM=y
From: "Mike Rapoport (IBM)"
powerpc overrides kprobes::alloc_insn_page() to remove writable
permissions when STRICT_MODULE_RWX is on.
Add definition of EXECMEM_KRPOBES to execmem_params to allow using the
generic kprobes::alloc_insn_page() with the desired permissions.
As po
From: "Mike Rapoport (IBM)"
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 suppo
From: "Mike Rapoport (IBM)"
The memory allocations for kprobes and BPF on arm64 can be placed
anywhere in vmalloc address space and currently this is implemented with
overrides of alloc_insn_page() and bpf_jit_alloc_exec() in arm64.
Define EXECMEM_KPROBES and EXECMEM_BPF range
From: "Mike Rapoport (IBM)"
Extend execmem parameters to accommodate more complex overrides of
module_alloc() by architectures.
This includes specification of a fallback range required by arm, arm64
and powerpc, EXECMEM_MODULE_DATA type required by powerpc, support for
allocatio
From: "Mike Rapoport (IBM)"
Several architectures override module_alloc() only to define address
range for code allocations different than VMALLOC address space.
Provide a generic implementation in execmem that uses the parameters for
address space ranges, required alignmen
From: "Mike Rapoport (IBM)"
module_alloc() is used everywhere as a mean to allocate memory for code.
Beside being semantically wrong, this unnecessarily ties all subsystems
that need to allocate code, such as ftrace, kprobes and BPF to modules and
puts the burden of code
From: "Mike Rapoport (IBM)"
Move the logic related to the memory allocation and freeing into
module_memory_alloc() and module_memory_free().
Signed-off-by: Mike Rapoport (IBM)
---
kernel/module/main.c | 64 +++-
1 file changed, 39 inserti
From: "Mike Rapoport (IBM)"
nios2 uses kmalloc() to implement module_alloc() because CALL26/PCREL26
cannot reach all of vmalloc address space.
Define module space as 32MiB below the kernel base and switch nios2 to
use vmalloc for module allocations.
Suggested-by: Thomas Gleix
From: "Mike Rapoport (IBM)"
and MODULE_END to MODULES_END to match other architectures that define
custom address space for modules.
Signed-off-by: Mike Rapoport (IBM)
---
arch/mips/include/asm/pgtable-64.h | 4 ++--
arch/mips/kernel/module.c | 4 ++--
arch/mips/
From: "Mike Rapoport (IBM)"
Since commit f6f37d9320a1 ("arm64: select KASAN_VMALLOC for SW/HW_TAGS
modes") KASAN_VMALLOC is always enabled when KASAN is on. This means
that allocations in module_alloc() will be tracked by KASAN protection
for vmalloc() and that kasan
From: "Mike Rapoport (IBM)"
Hi,
Since v3 I looked into making execmem more of an utility toolbox, as we
discussed at LPC with Mark Rutland, but it was getting more hairier than
having a struct describing architecture constraints and a type identifying
the consumer of execmem.
And
On Thu, Mar 28, 2024 at 04:32:38PM +0800, Baoquan He wrote:
> On 03/25/24 at 10:56pm, Baoquan He wrote:
> >
> > /*
> > -* Set an approximate value for lowmem here, it will be adjusted
> > -* when the bootmem allocator frees pages into the buddy system.
> > -
On Thu, Mar 28, 2024 at 07:09:13AM +0100, Arnd Bergmann wrote:
> On Thu, Mar 28, 2024, at 06:51, Vineet Gupta wrote:
> > On 3/27/24 09:22, Arnd Bergmann wrote:
> >> On Wed, Mar 27, 2024, at 16:39, David Hildenbrand wrote:
> >>> On 27.03.24 16:21, Peter Xu wrote:
> On Wed, Mar 27, 2024 at
On Mon, Mar 25, 2024 at 10:56:45PM +0800, Baoquan He wrote:
> Nobody calls calc_memmap_size() now.
>
> Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport (IBM)
Looks like I replied to patch 6/6 twice by mistake and missed this one.
> ---
> mm/mm_init.c | 20 ---
On Mon, Mar 25, 2024 at 10:56:46PM +0800, Baoquan He wrote:
> Since the current calculation of calc_nr_kernel_pages() has taken into
> consideration of kernel reserved memory, no need to have
> arch_reserved_kernel_pages() any more.
>
> Signed-off-by: Baoquan He
Reviewed-by: Mik
; case.
>
> And also clean up the outdated code comment above free_area_init_core().
> And free_area_init_core() is easy to understand now, no need to add
> words to explain.
>
> Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport (IBM)
> ---
> mm/mm_init.c | 46 +-
> 1 file changed, 5 insertions(+), 41 deletions(-)
ator, including HIGHMEM memory. While nr_kernel_pages counts up
> all free but not reserved low memory in memblock allocator, excluding
> HIGHMEM memory.
>
> Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport (IBM)
> ---
> mm/mm_init.c | 24
> 1 file
On Wed, Mar 27, 2024 at 02:05:38PM +0100, David Hildenbrand wrote:
> Let's fixup the remaining comments to consistently call that thing
> "GUP-fast". With this change, we consistently call it "GUP-fast".
>
> Signed-off-by: David Hildenbrand
Reviewed-by: M
et's make the config option reflect that.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport (IBM)
> ---
> arch/arm/Kconfig | 2 +-
> arch/arm64/Kconfig | 2 +-
> arch/loongarch/Kconfig | 2 +-
> arch/mips/Kconfig | 2 +-
> arch/powerpc/Kconfig | 2 +-
>
On Mon, Mar 25, 2024 at 10:56:46PM +0800, Baoquan He wrote:
> Since the current calculation of calc_nr_kernel_pages() has taken into
> consideration of kernel reserved memory, no need to have
> arch_reserved_kernel_pages() any more.
>
> Signed-off-by: Baoquan He
Reviewed-by: Mik
Hi Baoquan,
On Mon, Mar 25, 2024 at 10:56:43PM +0800, Baoquan He wrote:
> This is a preparation to calculate nr_kernel_pages and nr_all_pages,
> both of which will be used later in alloc_large_system_hash().
>
> nr_all_pages counts up all free but not reserved memory in memblock
> allocator,
On Mon, Mar 25, 2024 at 10:56:42PM +0800, Baoquan He wrote:
> Now nobody calls set_dma_reserve() to set value for dma_reserve, remove
> set_dma_reserve(), global variable dma_reserve and the codes using it.
>
> Signed-off-by: Baoquan He
Reviewed-by: Mike Rapoport (IBM)
> ---
&
ne's pcp and watermark setting are all done after mem_init(). So,
> no need to worry about the DMA zone's setting accuracy during
> free_area_init().
>
> Hence, remove memblock_find_dma_reserve() to stop calculating and
> setting dma_reserve.
>
> Signed-off-by: Baoquan He
On Wed, Mar 20, 2024 at 03:52:52PM +0800, Baoquan He wrote:
> On 03/19/24 at 05:49pm, Mike Rapoport wrote:
> > Hi Baoquan,
> >
> > On Mon, Mar 18, 2024 at 10:21:34PM +0800, Baoquan He wrote:
> > > This is not needed any more.
> >
> > I'd swap this an
On Mon, Mar 18, 2024 at 10:21:36PM +0800, Baoquan He wrote:
> Currently, in free_area_init_core(), when initialize zone's field, a
> rough value is set to zone->managed_pages. That value is calculated by
> (zone->present_pages - memmap_pages).
>
> In the meantime, add the value to nr_all_pages
Hi Baoquan,
On Mon, Mar 18, 2024 at 10:21:34PM +0800, Baoquan He wrote:
> This is not needed any more.
I'd swap this and the first patch, so that the first patch would remove
memblock_find_dma_reserve() and it's changelog will explain why it's not
needed and then the second patch will simply
On Fri, Mar 08, 2024 at 03:22:50PM -0800, Sean Christopherson wrote:
> On Fri, Mar 08, 2024, James Gowans wrote:
> > However, memfd_secret doesn’t work out the box for KVM guest memory; the
> > main reason seems to be that the GUP path is intentionally disabled for
> > memfd_secret, so if we use a
On Wed, Mar 06, 2024 at 12:05:10PM -0800, Calvin Owens wrote:
> If something like this is merged down the road, it can go in at leisure
> once the module_alloc change is in: it's a one-way dependency.
>
> Signed-off-by: Calvin Owens
> ---
> arch/Kconfig| 2 +-
>
might as well do it
> > now. And for that I'd just like to ask you paint the bikeshed with
> > Song Liu as he's been the one slowly making way to help us get there
> > with the "module: replace module_layout with module_memory",
> > and Mike Rapoport as he's
> Suggested-by: Jason Gunthorpe
> Signed-off-by: Peter Xu
Reviewed-by: Mike Rapoport (IBM)
> ---
> arch/riscv/include/asm/pgtable-64.h | 2 +-
> arch/riscv/include/asm/pgtable.h| 2 +-
> arch/s390/include/asm/pgtable.h | 4 ++--
> arch/sparc/include/asm/pgt
On Tue, Mar 05, 2024 at 12:37:49PM +0800, pet...@redhat.com wrote:
> From: Peter Xu
>
> They're not used anymore, drop all of them.
>
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Peter Xu
Reviewed-by: Mike Rapoport (IBM)
> ---
> arch/arm/include/asm/pgta
m/pgtable.c| 2 +-
> arch/x86/mm/pti.c| 4 ++--
> arch/x86/power/hibernate.c | 2 +-
> arch/x86/xen/mmu_pv.c| 4 ++--
> drivers/misc/sgi-gru/grufault.c | 2 +-
> 25 files changed, 49 insertions(+),
I for huge mappings. Use that to replace the trick.
>
> Cc: Andrey Ryabinin
> Cc: Alexander Potapenko
> Cc: Andrey Konovalov
> Cc: Dmitry Vyukov
> Cc: Vincenzo Frascino
> Cc: kasan-...@googlegroups.com
> Signed-off-by: Peter Xu
Reviewed-by: Mike Rapoport (IBM)
> ---
>
t; Cc: Dave Hansen
> Cc: x...@kernel.org
> Reviewed-by: Jason Gunthorpe
> Acked-by: Thomas Gleixner
> Signed-off-by: Peter Xu
Reviewed-by: Mike Rapoport (IBM)
> ---
> arch/x86/include/asm/pgtable.h | 1 -
> include/asm-generic/pgtable-nopmd.h | 1 -
> 2 files changed, 2
t; Cc: Dave Hansen
> Cc: x...@kernel.org
> Signed-off-by: Peter Xu
Reviewed-by: Mike Rapoport (IBM)
> ---
> arch/x86/include/asm/pgtable.h | 4 ++--
> arch/x86/mm/pti.c | 2 +-
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/arch/x86/inc
f now. So it also means after this
> patch we removed all p4d_large() usages.
>
> Cc: Thomas Gleixner
> Cc: Ingo Molnar
> Cc: Borislav Petkov
> Cc: Dave Hansen
> Cc: x...@kernel.org
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Peter Xu
Reviewed-by: Mike
dev@lists.ozlabs.org
> Suggested-by: Christophe Leroy
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Peter Xu
Reviewed-by: Mike Rapoport (IBM)
> ---
> arch/powerpc/include/asm/book3s/64/pgtable.h | 10
> arch/powerpc/include/asm/pgtable.h | 24 -
Cc: linuxppc-dev@lists.ozlabs.org
> Reviewed-by: Jason Gunthorpe
> Signed-off-by: Peter Xu
Reviewed-by: Mike Rapoport (IBM)
> ---
> arch/powerpc/include/asm/book3s/64/pgtable.h | 16 ++--
> arch/powerpc/include/asm/pgtable.h | 2 +-
> 2 files changed, 3
On Fri, Feb 23, 2024 at 03:57:27PM -0800, Alexei Starovoitov wrote:
> From: Alexei Starovoitov
>
> xen grant table and xenbus ring are not ioremap the way arch specific code is
> using it,
> so let's add VM_XEN flag to separate them from VM_IOREMAP users.
> xen will not and should not be
On Tue, Feb 27, 2024 at 03:51:25PM +0800, Yaxiong Tian wrote:
>
> 在 2024/2/26 17:14, Mike Rapoport 写道:
> > On Mon, Feb 26, 2024 at 09:37:06AM +0100, David Hildenbrand wrote:
> > > On 26.02.24 04:42, Yaxiong Tian wrote:
> > > > From: Yaxiong Tian
> > &g
On Mon, Feb 26, 2024 at 09:37:06AM +0100, David Hildenbrand wrote:
> On 26.02.24 04:42, Yaxiong Tian wrote:
> > From: Yaxiong Tian
> >
> > On ARM64 machines using UEFI, if the linear map is not set
> > (can_set_direct_map()
> > return false), swsusp_save() will fail due to can't finding the map
Hi Alex,
On Wed, Jan 17, 2024 at 02:46:56PM +, Alexander Graf wrote:
> We now have all bits in place to support KHO kexecs. This patch adds
> awareness of KHO in the kexec file as well as boot path for x86 and
> adds the respective kconfig option to the architecture so that it can
> use KHO
On Mon, Jan 29, 2024 at 01:46:45PM +0100, David Hildenbrand wrote:
> Let's prepare for further changes.
>
> Reviewed-by: Ryan Roberts
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport (IBM)
> ---
> mm/memory.c | 63 -
On Mon, Jan 29, 2024 at 01:46:46PM +0100, David Hildenbrand wrote:
> We already read it, let's just forward it.
>
> This patch is based on work by Ryan Roberts.
>
> Reviewed-by: Ryan Roberts
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport (IBM)
> -
viewed-by: Mike Rapoport (IBM)
> ---
> arch/powerpc/mm/pgtable.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/mm/pgtable.c b/arch/powerpc/mm/pgtable.c
> index a04ae4449a02..549a440ed7f6 100644
> --- a/arch/powerpc/mm/pgtable
On Mon, Jan 29, 2024 at 01:46:43PM +0100, David Hildenbrand wrote:
> Let's use our handy helper now that it's available on all archs.
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport (IBM)
> ---
> arch/arm/mm/mmu.c | 2 +-
> 1 file changed, 1 insert
r context.
>
> Reviewed-by: Christophe Leroy
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport (IBM)
> ---
> include/linux/pgtable.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
&
On Mon, Jan 29, 2024 at 01:46:41PM +0100, David Hildenbrand wrote:
> We want to make use of pte_next_pfn() outside of set_ptes(). Let's
> simply define PFN_PTE_SHIFT, required by pte_next_pfn().
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport (IBM)
> ---
>
On Mon, Jan 29, 2024 at 01:46:40PM +0100, David Hildenbrand wrote:
> We want to make use of pte_next_pfn() outside of set_ptes(). Let's
> simply define PFN_PTE_SHIFT, required by pte_next_pfn().
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport (IBM)
> ---
>
On Mon, Jan 29, 2024 at 01:46:39PM +0100, David Hildenbrand wrote:
> We want to make use of pte_next_pfn() outside of set_ptes(). Let's
> simply define PFN_PTE_SHIFT, required by pte_next_pfn().
>
> Reviewed-by: Alexandre Ghiti
> Signed-off-by: David Hildenbrand
Reviewed-by: Mik
On Mon, Jan 29, 2024 at 01:46:38PM +0100, David Hildenbrand wrote:
> We want to make use of pte_next_pfn() outside of set_ptes(). Let's
> simply define PFN_PTE_SHIFT, required by pte_next_pfn().
>
> Reviewed-by: Christophe Leroy
> Signed-off-by: David Hildenbrand
Reviewed-by
On Mon, Jan 29, 2024 at 01:46:37PM +0100, David Hildenbrand wrote:
> We want to make use of pte_next_pfn() outside of set_ptes(). Let's
> simply define PFN_PTE_SHIFT, required by pte_next_pfn().
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport (IBM)
> ---
>
On Mon, Jan 29, 2024 at 01:46:36PM +0100, David Hildenbrand wrote:
> We want to make use of pte_next_pfn() outside of set_ptes(). Let's
> simply define PFN_PTE_SHIFT, required by pte_next_pfn().
>
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport (IBM)
> ---
>
linux-mm/fdaeb9a5-d890-499a-92c8-d171df43a...@arm.com/
> Signed-off-by: Ryan Roberts
> Reviewed-by: Catalin Marinas
> Reviewed-by: David Hildenbrand
> Signed-off-by: David Hildenbrand
Reviewed-by: Mike Rapoport (IBM)
> ---
> arch/arm64/include/asm/pgtable.h | 28 ++
gt; depends on !STACK_GROWSUP
>
> +config ARCH_HAS_USER_SHADOW_STACK
> + bool
> + help
> + The architecture has hardware support for userspace shadow call
> + stacks (eg, x86 CET, arm64 GCS or RISC-V Zicfiss).
The whitespace looks suspicious, I think there should be a leading tab.
Otherwise
Reviewed-by: Mike Rapoport (IBM)
> +
> source "mm/damon/Kconfig"
>
> endmenu
>
> --
> 2.30.2
>
--
Sincerely yours,
Mike.
On Wed, Jan 24, 2024 at 09:19:00AM -0800, Lameter, Christopher wrote:
> On Tue, 23 Jan 2024, Huang Shijie wrote:
>
> > During the kernel booting, the generic cpu_to_node() is called too early in
> > arm64, powerpc and riscv when CONFIG_NUMA is enabled.
> >
> > For arm64/powerpc/riscv, there are
On Fri, Jan 19, 2024 at 04:50:53PM +0800, Shijie Huang wrote:
>
> 在 2024/1/19 16:42, Mike Rapoport 写道:
> > Is there a fundamental reason to have early_cpu_to_node() at all?
>
> The early_cpu_to_node does not work on some ARCHs (which support the NUMA),
> such as SPAR
On Fri, Jan 19, 2024 at 02:46:16PM +0800, Shijie Huang wrote:
>
> 在 2024/1/19 12:42, Yury Norov 写道:
> > This adds another level of indirection, I think. Currently cpu_to_node
> > is a simple inliner. After the patch it would be a real function with
> > all the associate overhead. Can you share a
On Thu, Dec 14, 2023 at 03:19:30PM +0500, Muhammad Usama Anjum wrote:
> The "locked-in-memory size" limit per process can be non-multiple of
> page_size. The mmap() fails if we try to allocate locked-in-memory
> with same size as the allowed limit if it isn't multiple of the
> page_size because
On Mon, Nov 27, 2023 at 11:52:56AM +, Alexandru Elisei wrote:
> Hi Mike,
>
> I really appreciate you having a look!
>
> On Sat, Nov 25, 2023 at 12:03:22PM +0200, Mike Rapoport wrote:
> > On Sun, Nov 19, 2023 at 04:56:58PM +, Alexandru Elisei wrote:
> &
On Sun, Nov 19, 2023 at 04:56:58PM +, Alexandru Elisei wrote:
> It might be desirable for an architecture to modify the gfp flags used to
> allocate the destination page for migration based on the page that it is
> being replaced. For example, if an architectures has metadata associated
> with
On Thu, Oct 26, 2023 at 11:24:39AM +0100, Will Deacon wrote:
> On Thu, Oct 26, 2023 at 11:58:00AM +0300, Mike Rapoport wrote:
> > On Mon, Oct 23, 2023 at 06:14:20PM +0100, Will Deacon wrote:
> > > On Mon, Sep 18, 2023 at 10:29:46AM +0300, Mike Rapoport wrote:
> > > >
On Thu, Oct 26, 2023 at 11:24:39AM +0100, Will Deacon wrote:
> On Thu, Oct 26, 2023 at 11:58:00AM +0300, Mike Rapoport wrote:
> > On Mon, Oct 23, 2023 at 06:14:20PM +0100, Will Deacon wrote:
> > > On Mon, Sep 18, 2023 at 10:29:46AM +0300, Mike Rapoport wrote:
> > > >
Hi Will,
On Mon, Oct 23, 2023 at 06:14:20PM +0100, Will Deacon wrote:
> Hi Mike,
>
> On Mon, Sep 18, 2023 at 10:29:46AM +0300, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Extend execmem parameters to accommodate more complex overrides o
Hi Will,
On Mon, Oct 23, 2023 at 06:14:20PM +0100, Will Deacon wrote:
> Hi Mike,
>
> On Mon, Sep 18, 2023 at 10:29:46AM +0300, Mike Rapoport wrote:
> > From: "Mike Rapoport (IBM)"
> >
> > Extend execmem parameters to accommodate more complex overrides o
Hi Rick,
Sorry for the delay, I was a bit preoccupied with $stuff.
On Thu, Oct 05, 2023 at 06:09:07PM +, Edgecombe, Rick P wrote:
> On Thu, 2023-10-05 at 08:26 +0300, Mike Rapoport wrote:
> > On Wed, Oct 04, 2023 at 03:39:26PM +, Edgecombe, Rick P wrote:
> > > On Tue, 2
Hi Rick,
Sorry for the delay, I was a bit preoccupied with $stuff.
On Thu, Oct 05, 2023 at 06:09:07PM +, Edgecombe, Rick P wrote:
> On Thu, 2023-10-05 at 08:26 +0300, Mike Rapoport wrote:
> > On Wed, Oct 04, 2023 at 03:39:26PM +, Edgecombe, Rick P wrote:
> > > On Tue, 2
On Wed, Oct 04, 2023 at 12:29:36AM +, Edgecombe, Rick P wrote:
> On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> > diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
> > index 5f71a0cf4399..9d37375e2f05 100644
> > --- a/arch/x86/kernel/module.c
>
On Wed, Oct 04, 2023 at 12:29:36AM +, Edgecombe, Rick P wrote:
> On Mon, 2023-09-18 at 10:29 +0300, Mike Rapoport wrote:
> > diff --git a/arch/x86/kernel/module.c b/arch/x86/kernel/module.c
> > index 5f71a0cf4399..9d37375e2f05 100644
> > --- a/arch/x86/kernel/module.c
>
On Wed, Oct 04, 2023 at 03:39:26PM +, 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
On Wed, Oct 04, 2023 at 03:39:26PM +, 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
Hi Arnd,
On Tue, Sep 26, 2023 at 09:33:48AM +0200, Arnd Bergmann wrote:
> On Mon, Sep 18, 2023, at 09:29, Mike Rapoport wrote:
> > index a42e4cd11db2..c0b536e398b4 100644
> > --- a/arch/arm/mm/init.c
> > +++ b/arch/arm/mm/init.c
> > +#ifdef CONFIG_XIP_KERNEL
> >
Hi Arnd,
On Tue, Sep 26, 2023 at 09:33:48AM +0200, Arnd Bergmann wrote:
> On Mon, Sep 18, 2023, at 09:29, Mike Rapoport wrote:
> > index a42e4cd11db2..c0b536e398b4 100644
> > --- a/arch/arm/mm/init.c
> > +++ b/arch/arm/mm/init.c
> > +#ifdef CONFIG_XIP_KERNEL
> >
On Sat, Sep 23, 2023 at 03:36:01PM -0700, Song Liu wrote:
> On Sat, Sep 23, 2023 at 8:39 AM Mike Rapoport wrote:
> >
> > On Thu, Sep 21, 2023 at 03:34:18PM -0700, Song Liu wrote:
> > > On Mon, Sep 18, 2023 at 12:30 AM Mike Rapoport wrote:
> > > >
> > >
On Sat, Sep 23, 2023 at 03:36:01PM -0700, Song Liu wrote:
> On Sat, Sep 23, 2023 at 8:39 AM Mike Rapoport wrote:
> >
> > On Thu, Sep 21, 2023 at 03:34:18PM -0700, Song Liu wrote:
> > > On Mon, Sep 18, 2023 at 12:30 AM Mike Rapoport wrote:
> > > >
> > >
Hi Christophe,
On Fri, Sep 22, 2023 at 10:32:46AM +, Christophe Leroy wrote:
> Hi Mike,
>
> Le 18/09/2023 à 09:29, Mike Rapoport a écrit :
> > From: "Mike Rapoport (IBM)"
> >
> > powerpc overrides kprobes::alloc_insn_page() to remove writable
&
Hi Christophe,
On Fri, Sep 22, 2023 at 10:32:46AM +, Christophe Leroy wrote:
> Hi Mike,
>
> Le 18/09/2023 à 09:29, Mike Rapoport a écrit :
> > From: "Mike Rapoport (IBM)"
> >
> > powerpc overrides kprobes::alloc_insn_page() to remove writable
&
On Thu, Sep 21, 2023 at 03:30:46PM -0700, Song Liu wrote:
> On Mon, Sep 18, 2023 at 12:31 AM Mike Rapoport wrote:
> >
> [...]
> > @@ -135,5 +138,13 @@ struct execmem_params __init *execmem_arch_params(void)
> >
> > range->pgprot = prot;
>
On Thu, Sep 21, 2023 at 03:30:46PM -0700, Song Liu wrote:
> On Mon, Sep 18, 2023 at 12:31 AM Mike Rapoport wrote:
> >
> [...]
> > @@ -135,5 +138,13 @@ struct execmem_params __init *execmem_arch_params(void)
> >
> > range->pgprot = prot;
>
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)"
> >
> > The memory allocations for kprobes and BPF on RISC-V are not placed in
> > th
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)"
> >
> > The memory allocations for kprobes and BPF on RISC-V are not placed in
> > th
On Thu, Sep 21, 2023 at 03:52:21PM -0700, Song Liu wrote:
> On Mon, Sep 18, 2023 at 12:31 AM Mike Rapoport wrote:
> >
> [...]
> > diff --git a/include/linux/execmem.h b/include/linux/execmem.h
> > index 519bdfdca595..09d45ac786e9 100644
> > --- a/include/linux/exe
On Thu, Sep 21, 2023 at 03:52:21PM -0700, Song Liu wrote:
> On Mon, Sep 18, 2023 at 12:31 AM Mike Rapoport wrote:
> >
> [...]
> > diff --git a/include/linux/execmem.h b/include/linux/execmem.h
> > index 519bdfdca595..09d45ac786e9 100644
> > --- a/include/linux/exe
On Thu, Sep 21, 2023 at 03:10:26PM -0700, Song Liu wrote:
> On Mon, Sep 18, 2023 at 12:30 AM Mike Rapoport wrote:
> >
> [...]
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static void *execmem_alloc(si
On Thu, Sep 21, 2023 at 03:10:26PM -0700, Song Liu wrote:
> On Mon, Sep 18, 2023 at 12:30 AM Mike Rapoport wrote:
> >
> [...]
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +static void *execmem_alloc(si
On Thu, Sep 21, 2023 at 03:14:54PM -0700, Song Liu wrote:
> On Mon, Sep 18, 2023 at 12:30 AM Mike Rapoport wrote:
> >
> [...]
> > +
> > +/**
> > + * enum execmem_type - types of executable memory ranges
> > + *
> > + * There are several
On Thu, Sep 21, 2023 at 03:14:54PM -0700, Song Liu wrote:
> On Mon, Sep 18, 2023 at 12:30 AM Mike Rapoport wrote:
> >
> [...]
> > +
> > +/**
> > + * enum execmem_type - types of executable memory ranges
> > + *
> > + * There are several
On Thu, Sep 21, 2023 at 03:34:18PM -0700, Song Liu wrote:
> On Mon, Sep 18, 2023 at 12:30 AM Mike Rapoport wrote:
> >
>
> [...]
>
> > diff --git a/arch/s390/kernel/module.c b/arch/s390/kernel/module.c
> > index 42215f9404af..db5561d0c233 100644
> > --- a/arch
On Thu, Sep 21, 2023 at 03:34:18PM -0700, Song Liu wrote:
> On Mon, Sep 18, 2023 at 12:30 AM Mike Rapoport wrote:
> >
>
> [...]
>
> > diff --git a/arch/s390/kernel/module.c b/arch/s390/kernel/module.c
> > index 42215f9404af..db5561d0c233 100644
> > --- a/arch
From: "Mike Rapoport (IBM)"
Several architectures override module_alloc() only to define address
range for code allocations different than VMALLOC address space.
Provide a generic implementation in execmem that uses the parameters
for address space ranges, required alignmen
From: "Mike Rapoport (IBM)"
BPF just-in-time compiler depended on CONFIG_MODULES because it used
module_alloc() to allocate memory for the generated code.
Since code allocations are now implemented with execmem, drop dependency of
CONFIG_BPF_JIT on CONFIG_MODULES and make
301 - 400 of 6442 matches
Mail list logo
