Re: [PATCH v2 1/3] module: Rename module_alloc() to text_alloc() and move to kernel proper

On Thu, Jul 23, 2020 at 03:42:09PM +0300, Ard Biesheuvel wrote:

On Thu, 23 Jul 2020 at 04:52, Jarkko Sakkinen
[off-list ref] wrote:

quoted

On Thu, Jul 16, 2020 at 06:49:09PM +0200, Christophe Leroy wrote:

quoted

Jarkko Sakkinen [off-list ref] a écrit :

quoted

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.sakkinen@linux.intel.com/ (local)

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