On 10/1/26 06:22, Frédéric MARIE-JOSEPH wrote:
> That's my first post so I hope I do things right. I found what seems to
> me like a bug, and worked with Claude to find a patch. Hope it will be
> usefull.

Your mailer is sending out HTML, but there was a plain-text version too,
so the message at least made it to the archives. Using git-send-email is
the most foolproof way to send these things, fwiw.

> With CONFIG_MODULES=n there is no STRICT_MODULE_RWX, so x86 does not
> select ARCH_HAS_EXECMEM_ROX and execmem_restore_rox() is the stub that
> returns 0.

Ugh. The origin of this seems to be:

         select ARCH_HAS_EXECMEM_ROX             if X86_64 &&
STRICT_MODULE_RWX
from:

> commit 47410d839fcda6890cb82828f874f97710982f24
> Author: Mike Rapoport (Microsoft) <rppt@kernel.org>
> Date:   Tue Jun 3 14:14:42 2025 +0300
> 
>     x86/Kconfig: only enable ROX cache in execmem when STRICT_MODULE_RWX is set

That commit is trying to change execmem internal details via an
arch-specific Kconfig tweak. It's also logically a bit silly that what
an arch supports:

	ARCH_HAS_EXECMEM_ROX

depends on a module-specific option:

	STRICT_MODULE_RWX

If execmem is being too aggressive on for modules on !STRICT_MODULE_RWX
configs, shouldn't the fix be in execmem *module* code?

Maybe something along the line of the lightly-tested attached patch? I
see the "11 W+X pages found" message without it, and the message goes
away when it is applied.