[PATCH v2 8/8] x86/module: enable ROX caches for module text

From: "Mike Rapoport (Microsoft)" Enable execmem's cache of PMD_SIZE'ed pages mapped as ROX for module text allocations. Signed-off-by: Mike Rapoport (Microsoft) --- arch/x86/mm/init.c | 26 +- 1 file changed, 25 insertions(+), 1 deletion(-) diff --git a/arch/x86/mm/in

[PATCH v2 7/8] execmem: add support for cache of large ROX pages

From: "Mike Rapoport (Microsoft)" Using large pages to map text areas reduces iTLB pressure and improves performance. Extend execmem_alloc() with an ability to use PMD_SIZE'ed pages with ROX permissions as a cache for smaller allocations. To populate the cache, a writable large page is allocate

[PATCH v2 6/8] x86/module: perpare module loading for ROX allocations of text

From: "Mike Rapoport (Microsoft)" When module text memory will be allocated with ROX permissions, the memory at the actual address where the module will live will contain invalid instructions and there will be a writable copy that contains the actual module code. Update relocations and alternati

[PATCH v2 5/8] ftrace: Add swap_func to ftrace_process_locs()

From: Song Liu ftrace_process_locs sorts module mcount, which is inside RO memory. Add a ftrace_swap_func so that archs can use RO-memory-poke function to do the sorting. Signed-off-by: Song Liu Signed-off-by: Mike Rapoport (Microsoft) --- include/linux/ftrace.h | 2 ++ kernel/trace/ftrace.c

[PATCH v2 4/8] module: prepare to handle ROX allocations for text

From: "Mike Rapoport (Microsoft)" 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 module loading e

[PATCH v2 3/8] asm-generic: introduce text-patching.h

From: "Mike Rapoport (Microsoft)" 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 support text pa

[PATCH v2 2/8] mm: vmalloc: don't account for number of nodes for HUGE_VMAP allocations

From: "Mike Rapoport (Microsoft)" vmalloc allocations with VM_ALLOW_HUGE_VMAP that do not explicitly specify node ID will use huge pages only if size_per_node is larger than a huge page. Still the actual allocated memory is not distributed between nodes and there is no advantage in such approach.

[PATCH v2 1/8] mm: vmalloc: group declarations depending on CONFIG_MMU together

From: "Mike Rapoport (Microsoft)" There are a couple of declarations that depend on CONFIG_MMU in include/linux/vmalloc.h spread all over the file. Group them all together to improve code readability. No functional changes. Signed-off-by: Mike Rapoport (Microsoft) --- include/linux/vmalloc.h

[PATCH v2 0/8] x86/module: use large ROX pages for text allocations

From: "Mike Rapoport (Microsoft)" 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 memory along w

Re: clearly mark DMA_OPS support as an architecture feasture

On Mon, Aug 26, 2024 at 2:30 PM Christoph Hellwig wrote: > > On Mon, Aug 26, 2024 at 02:27:27PM +0800, Jason Wang wrote: > > Actually I meant, we can extend the virtio_config_ops to allow mapping > > ops there, then simulator and VDUSE can hook the map ops there. > > From a quick glance that feels

Re: clearly mark DMA_OPS support as an architecture feasture

On Mon, Aug 26, 2024 at 02:27:27PM +0800, Jason Wang wrote: > Actually I meant, we can extend the virtio_config_ops to allow mapping > ops there, then simulator and VDUSE can hook the map ops there. >From a quick glance that feels like the right layer of abstraction, although the config part of th

Re: clearly mark DMA_OPS support as an architecture feasture

On Mon, Aug 26, 2024 at 2:16 PM Jason Wang wrote: > > On Sat, Aug 24, 2024 at 11:58 AM Christoph Hellwig wrote: > > > > Hi all, > > > > we've had a long standing problems where drivers try to hook into the > > DMA_OPS mechanisms to override them for something that is not DMA, or > > to introduce

Re: clearly mark DMA_OPS support as an architecture feasture

On Sat, Aug 24, 2024 at 11:58 AM Christoph Hellwig wrote: > > Hi all, > > we've had a long standing problems where drivers try to hook into the > DMA_OPS mechanisms to override them for something that is not DMA, or > to introduce additional dispatching. > > Now that we are not using DMA_OPS suppo

Re: [PATCH] dma-mapping: clear mark DMA ops as an architecture feature

On Sat, Aug 24 2024 at 05:57, Christoph Hellwig wrote: > DMA ops are a helper for architectures and not for drivers to override > the DMA implementation. Unfortunately driver authors keep ignoring > this. Make this more clear by renaming the symbol to ARCH_DMA_OPS, > have the three drivers overri