Le 25/01/2022 à 22:10, Luis Chamberlain a écrit : > On Mon, Jan 24, 2022 at 09:22:34AM +0000, Christophe Leroy wrote: >> This can also be useful on other powerpc/32 in order to maximize the >> chance of code being close enough to kernel core to avoid branch >> trampolines. > > Curious about all this branch trampoline talk. Do you have data to show > negative impact with things as-is? See https://github.com/linuxppc/linux/commit/2ec13df167040cd153c25c4d96d0ffc573ac4c40 Or https://github.com/linuxppc/linux/commit/7d485f647c1f4a6976264c90447fb0dbf07b111d > > Also, was powerpc/32 broken then without this? The commit log seems to > suggest so, but I don't think that's the case. How was this issue noticed? Your question is related to the trampoline topic or the exec/noexec flagging ? Regarding trampoline, everything is working OK. That's just cherry on the cake, when putting data away you can have more code closer to the kernel. But that would not have been a reason in itself for this series. Regarding the exec/noexec discussion, it's a real issue. powerpc/32 doesn't honor page exec flag, so when you select STRICT_MODULES_RWX and flag module data as no-exec, it remains executable. That's because powerpc/32 MMU doesn't have a per page exec flag but only a per 256Mbytes segment exec flag. Typical PPC32 layount: 0xf0000000-0xffffffff : VMALLOC AREA ==> NO EXEC 0xc0000000-0xefffffff : Linear kernel memory mapping 0xb0000000-0xbfffffff : MODULES AREA ==> EXEC 0x00000000-0xafffffff : User space ==> EXEC So STRICT_MODULES_RWX is broken on some powerpc/32 > > Are there other future CPU families being planned where this is all true for > as well? Are they goin to be 32-bit as well? Future I don't know. Regarding the trampoline stuff, I see at least the following existing architectures with a similar constraint: ARM: https://elixir.bootlin.com/linux/v5.16/source/arch/arm/include/asm/memory.h#L55 ARM even has a config item to allow trampolines or not. I might add the same to powerpc to reduce number of pages used by modules. https://elixir.bootlin.com/linux/v5.16/source/arch/arm/Kconfig#L1514 NDS32 has the constraint https://elixir.bootlin.com/linux/v5.16/source/arch/nds32/include/asm/memory.h#L41 NIOS2 has the constraint, allthough they handled it in a different way: https://elixir.bootlin.com/linux/v5.16/source/arch/nios2/kernel/module.c#L30 Even ARM64 benefits from modules closer to kernel: https://elixir.bootlin.com/linux/v5.16/source/arch/arm64/Kconfig#L1848 Another future opportunity with the ability to allocate module parts separately is the possibility to then use huge vmalloc mappings. Today huge vmalloc mappings cannot be used for modules, see recent discussion at https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20211227145903.187152-4-wangkefeng.wang@xxxxxxxxxx/ Christophe
