On Thu, Jul 23, 2020 at 03:42:09PM +0300, Ard Biesheuvel wrote: > On Thu, 23 Jul 2020 at 04:52, Jarkko Sakkinen > <jarkko.sakki...@linux.intel.com> wrote: > > > > On Thu, Jul 16, 2020 at 06:49:09PM +0200, Christophe Leroy wrote: > > > Jarkko Sakkinen <jarkko.sakki...@linux.intel.com> a écrit : > > > > > > > Rename module_alloc() to text_alloc() and module_memfree() to > > > > text_memfree(), and move them to kernel/text.c, which is unconditionally > > > > compiled to the kernel proper. This allows kprobes, ftrace and bpf to > > > > allocate space for executable code without requiring to compile the > > > > modules > > > > support (CONFIG_MODULES=y) in. > > > > > > You are not changing enough in powerpc to have this work. > > > On powerpc 32 bits (6xx), when STRICT_KERNEL_RWX is selected, the vmalloc > > > space is set to NX (no exec) at segment level (ie by 256Mbytes zone) > > > unless > > > CONFIG_MODULES is selected. > > > > > > Christophe > > > > This has been deduced down to: > > > > https://lore.kernel.org/lkml/20200717030422.679972-1-jarkko.sakki...@linux.intel.com/ > > > > I.e. not intruding PPC anymore :-) > > > > Ok, so after the elaborate discussion we had between Jessica, Russell, > Peter, Will, Mark, you and myself, where we pointed out that > a) a single text_alloc() abstraction for bpf, kprobes and ftrace does > not fit other architectures very well, and > b) that module_alloc() is not suitable as a default to base text_alloc() on,
In the latest iteration (v5) it is conditionally available only if arch defines and fallback has been removed. > you went ahead and implemented that anyway, but only cc'ing Peter, > akpm, Masami and the mm list this time? No problems with that. Actually each patch gets everything that get_maintainer.pl gives with a cc cmd script, not just the ones explicitly listed in the patch. Should I explicitly CC you to the next version? I'm happy to grow the list when requested. > Sorry, but that is not how it works. Once people get pulled into a > discussion, you cannot dismiss them or their feedback like that and go > off and do your own thing anyway. Generic features like this are > tricky to get right, and it will likely take many iterations and input > from many different people. Sure. I'm not expecting this move quickly. I don't think I've at least purposely done that. As you said it's tricky to get this right. /Jarkko
