Re: [PATCH v6 6/8] x86/module: prepare module loading for ROX allocations of text
On Thu, Oct 17, 2024 at 10:17:12AM -0400, Steven Rostedt wrote:
> On Wed, 16 Oct 2024 17:01:28 -0400
> Steven Rostedt wrote:
>
> > If this is only needed for module load, can we at least still use the
> > text_poke_early() at boot up?
> >
> > if (ftrace_poke_late) {
> > text_poke_queue((void *)ip, new_code, MCOUNT_INSN_SIZE, NULL);
> > } else if (system_state == SYSTEM_BOOTING) {
> > text_poke_early((void *)ip, new_code, MCOUNT_INSN_SIZE);
> > } else {
> > mutex_lock(&text_mutex);
> > text_poke((void *)ip, new_code, MCOUNT_INSN_SIZE);
> > mutex_unlock(&text_mutex);
> > }
> >
> > ?
> >
> > The above if statement looks to slow things down just slightly, but only by
> > 2ms, which is more reasonable.
>
> I changed the above to this (yes it's a little hacky) and got my 2ms back!
>
> -- Steve
>
> DEFINE_STATIC_KEY_TRUE(ftrace_modify_boot);
>
> static int __init ftrace_boot_init_done(void)
> {
> static_branch_disable(&ftrace_modify_boot);
> return 0;
> }
> /* Ftrace updates happen before core init */
> core_initcall(ftrace_boot_init_done);
We can also pass mod to ftrace_modify_code_direct() and use that to
distinguish early boot and ftrace_module_init.
With this I get very similar numbers like with the static branch
diff --git a/arch/x86/kernel/ftrace.c b/arch/x86/kernel/ftrace.c
index 8da0e66ca22d..859902dd06fc 100644
--- a/arch/x86/kernel/ftrace.c
+++ b/arch/x86/kernel/ftrace.c
@@ -111,17 +111,22 @@ static int ftrace_verify_code(unsigned long ip, const
char *old_code)
*/
static int __ref
ftrace_modify_code_direct(unsigned long ip, const char *old_code,
- const char *new_code)
+ const char *new_code, struct module *mod)
{
int ret = ftrace_verify_code(ip, old_code);
if (ret)
return ret;
/* replace the text with the new text */
- if (ftrace_poke_late)
+ if (ftrace_poke_late) {
text_poke_queue((void *)ip, new_code, MCOUNT_INSN_SIZE, NULL);
- else
+ } else if (!mod) {
text_poke_early((void *)ip, new_code, MCOUNT_INSN_SIZE);
+ } else {
+ mutex_lock(&text_mutex);
+ text_poke((void *)ip, new_code, MCOUNT_INSN_SIZE);
+ mutex_unlock(&text_mutex);
+ }
return 0;
}
@@ -142,7 +147,7 @@ int ftrace_make_nop(struct module *mod, struct dyn_ftrace
*rec, unsigned long ad
* just modify the code directly.
*/
if (addr == MCOUNT_ADDR)
- return ftrace_modify_code_direct(ip, old, new);
+ return ftrace_modify_code_direct(ip, old, new, mod);
/*
* x86 overrides ftrace_replace_code -- this function will never be used
@@ -161,7 +166,7 @@ int ftrace_make_call(struct dyn_ftrace *rec, unsigned long
addr)
new = ftrace_call_replace(ip, addr);
/* Should only be called when module is loaded */
- return ftrace_modify_code_direct(rec->ip, old, new);
+ return ftrace_modify_code_direct(rec->ip, old, new, NULL);
}
/*
--
Sincerely yours,
Mike.
___
linux-snps-arc mailing list
linux-snps-arc@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 5/8] arch: introduce set_direct_map_valid_noflush()
On Wed, Oct 16, 2024 at 03:24:21PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > Add an API that will allow updates of the direct/linear map for a set of > physically contiguous pages. > > It will be used in the following patches. > > Signed-off-by: Mike Rapoport (Microsoft) > Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 2/8] mm: vmalloc: don't account for number of nodes for HUGE_VMAP allocations
On Wed, Oct 16, 2024 at 03:24:18PM +0300, Mike Rapoport wrote: > 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. > On the contrary, BPF allocates SZ_2M * num_possible_nodes() for each > new bpf_prog_pack, while it could do with a single huge page per pack. > > Don't account for number of nodes for VM_ALLOW_HUGE_VMAP with > NUMA_NO_NODE and use huge pages whenever the requested allocation size > is larger than a huge page. > > Signed-off-by: Mike Rapoport (Microsoft) > Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 3/8] asm-generic: introduce text-patching.h
On Wed, Oct 16, 2024 at 03:24:19PM +0300, Mike Rapoport wrote: > 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 patching. > > Signed-off-by: Mike Rapoport (Microsoft) > Reviewed-by: Christoph Hellwig > Acked-by: Geert Uytterhoeven # m68k > Acked-by: Arnd Bergmann Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 4/8] module: prepare to handle ROX allocations for text
On Wed, Oct 16, 2024 at 03:24:20PM +0300, Mike Rapoport wrote: > 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 > extremely slow and will expose executable code that is not finally formed. > > A better way is to have memory allocated with ROX permissions contain > invalid instructions and keep a writable, but not executable copy of the > module text. The relocations and alternative patches would be done on the > writable copy using the addresses of the ROX memory. > Once the module is completely ready, the updated text will be copied to ROX > memory using text patching in one go and the writable copy will be freed. > > Add support for that to module initialization code and provide necessary > interfaces in execmem. > > Signed-off-by: Mike Rapoport (Microsoft) Reviewd-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 7/8] execmem: add support for cache of large ROX pages
On Wed, Oct 16, 2024 at 03:24:23PM +0300, Mike Rapoport wrote: > 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 huge pages with ROX > permissions as a cache for smaller allocations. > > To populate the cache, a writable large page is allocated from vmalloc with > VM_ALLOW_HUGE_VMAP, filled with invalid instructions and then remapped as > ROX. > > The direct map alias of that large page is exculded from the direct map. > > Portions of that large page are handed out to execmem_alloc() callers > without any changes to the permissions. > > When the memory is freed with execmem_free() it is invalidated again so > that it won't contain stale instructions. > > An architecture has to implement execmem_fill_trapping_insns() callback > and select ARCH_HAS_EXECMEM_ROX configuration option to be able to use > the ROX cache. > > The cache is enabled on per-range basis when an architecture sets > EXECMEM_ROX_CACHE flag in definition of an execmem_range. > > Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 8/8] x86/module: enable ROX caches for module text on 64 bit
On Wed, Oct 16, 2024 at 03:24:24PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > Enable execmem's cache of PMD_SIZE'ed pages mapped as ROX for module > text allocations on 64 bit. > > Signed-off-by: Mike Rapoport (Microsoft) Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 0/8] x86/module: use large ROX pages for text allocations
On Wed, Oct 16, 2024 at 03:24:16PM +0300, Mike Rapoport wrote: > From: "Mike Rapoport (Microsoft)" > > Hi, > > This is an updated version of execmem ROX caches. > > Andrew, Luis, there is a conflict with Suren's "page allocation tag > compression" patches: > > https://lore.kernel.org/all/20241014203646.1952505-1-sur...@google.com > > Probably taking this via mmotm would be more convenient. Yeah, it's already there on Andrew's tree, fine with me to go through there. The linux modules KPD [0] has picked this up from the mailing list and tested with kdevops, and this series passes our modules test now [1], and so: Tested-by: kdevops [1] Link https://github.com/linux-kdevops/linux-modules-kpd/actions/runs/11420097546 # [0] Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
Re: [PATCH v6 1/8] mm: vmalloc: group declarations depending on CONFIG_MMU together
On Wed, Oct 16, 2024 at 03:24:17PM +0300, Mike Rapoport wrote: > 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) > Reviewed-by: Christoph Hellwig Reviewed-by: Luis Chamberlain Luis ___ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
