[PATCH] um: mprotect() __init memory

[Johannes Berg]

On Sat, 2026-09-26 at 11:12 +0900, Hajime Tazaki wrote:
> Hello,
> 
> I recently pulled uml/next branch and faced an issue on the exit.
> 
> ```
> Thread 1 "vmlinux" received signal SIGSEGV, Segmentation fault.
> 0x0000000060003cf3 in start_uml () at ../arch/um/kernel/skas/process.c:41
> 41      }
> (gdb) bt
> #0  0x0000000060003cf3 in start_uml () at ../arch/um/kernel/skas/process.c:41
> #1  0x0000000060003a69 in linux_main (argc=argc at entry=9, argv=argv at entry=0x7fffffffe118,
>     envp=envp at entry=0x7fffffffe168) at ../arch/um/kernel/um_arch.c:404
> #2  0x00000000600049dc in main (argc=9, argv=0x7fffffffe118, envp=0x7fffffffe168)
>     at ../arch/um/os-Linux/main.c:153
> ```
> 
> and bisected that this commit is the first rev to introduce this.

I didn't get that, hmm.

> indeed, now .text section is in __init label but some of startup code
> (start_uml, linux_main) remain un-returned even after init is done.
> 
> a quick change below avoid this issue, but not sure if it is your
> intention of the original patch.

No, clearly not - we shouldn't execute __init code after init either :)

So I guess we found a but elsewhere, but I don't immediately see what
needs to be not marked __init, clearly linux_main() is still used on the
way out so that must be, but ...

Or we could mprotect(..., 0, 0, 1) internally on the way out again,
since really _while_ running we also shouldn't be in __init code, it's
just a side effect of how UML shuts down?

Got a config or so? I really don't see this.

johannes