From: Hajime Tazaki <thehajime@gmail.com>
To: johannes@sipsolutions.net
Cc: linux-um@lists.infradead.org, johannes.berg@intel.com
Subject: Re: [PATCH] um: mprotect() __init memory
Date: Sat, 26 Sep 2026 11:12:49 +0900 [thread overview]
Message-ID: <m24ifc4v6m.wl-thehajime@gmail.com> (raw)
In-Reply-To: <20260921122937.3821fec01e82.Ib959ff1baad7a45e2b804209b530040e69e4b046@changeid>
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@entry=9, argv=argv@entry=0x7fffffffe118,
envp=envp@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.
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.
--- a/arch/um/kernel/mem.c
+++ b/arch/um/kernel/mem.c
@@ -93,7 +93,7 @@ void free_initmem(void)
unsigned long end = round_down((unsigned long)__init_end, PAGE_SIZE);
if (end > start)
- os_protect_memory((void *)start, end - start, 0, 0, 0);
+ os_protect_memory((void *)start, end - start, 0, 0, 1);
}
I guess you're already aware of it (if you boot and halt a UML
instance it should be 100% reproducible), but in case not.
-- Hajime
On Mon, 21 Sep 2026 19:29:37 +0900,
Johannes Berg wrote:
>
> From: Johannes Berg <johannes.berg@intel.com>
>
> Unlike what the comment says, we could munmap() this (but
> not reuse it for guest allocations), but then stray libc
> allocations could technically conflict, so mprotect() it
> to catch access bugs. Align it in the linker scripts too
> so that all of it can be covered, not just some.
>
> Signed-off-by: Johannes Berg <johannes.berg@intel.com>
> ---
> arch/um/kernel/dyn.lds.S | 2 ++
> arch/um/kernel/mem.c | 11 ++++++++---
> arch/um/kernel/uml.lds.S | 2 ++
> 3 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/arch/um/kernel/dyn.lds.S b/arch/um/kernel/dyn.lds.S
> index ad3cefeff2ac..5d3d5ef6ebec 100644
> --- a/arch/um/kernel/dyn.lds.S
> +++ b/arch/um/kernel/dyn.lds.S
> @@ -98,8 +98,10 @@ SECTIONS
>
> #include <asm/common.lds.S>
>
> + . = ALIGN(PAGE_SIZE);
> __init_begin = .;
> init.data : { INIT_DATA }
> + . = ALIGN(PAGE_SIZE);
> __init_end = .;
>
> /* Ensure the __preinit_array_start label is properly aligned. We
> diff --git a/arch/um/kernel/mem.c b/arch/um/kernel/mem.c
> index 1eef0e42ef5d..00c469fd28ee 100644
> --- a/arch/um/kernel/mem.c
> +++ b/arch/um/kernel/mem.c
> @@ -83,12 +83,17 @@ void __init arch_zone_limits_init(unsigned long *max_zone_pfns)
> }
>
> /*
> - * This can't do anything because nothing in the kernel image can be freed
> - * since it's not in kernel physical memory.
> + * We could munmap() this instead, but then libc allocations could
> + * land in this area and stray initdata access could erroneosly
> + * succeeded - just mprotect() it to reliably catch bad accesses.
> */
> -
> void free_initmem(void)
> {
> + unsigned long start = PAGE_ALIGN((unsigned long)__init_begin);
> + unsigned long end = round_down((unsigned long)__init_end, PAGE_SIZE);
> +
> + if (end > start)
> + os_protect_memory((void *)start, end - start, 0, 0, 0);
> }
>
> /* Allocate and free page tables. */
> diff --git a/arch/um/kernel/uml.lds.S b/arch/um/kernel/uml.lds.S
> index 30aa24348d60..7085ba6fcb93 100644
> --- a/arch/um/kernel/uml.lds.S
> +++ b/arch/um/kernel/uml.lds.S
> @@ -70,8 +70,10 @@ SECTIONS
>
> #include <asm/common.lds.S>
>
> + . = ALIGN(PAGE_SIZE);
> __init_begin = .;
> init.data : { INIT_DATA }
> + . = ALIGN(PAGE_SIZE);
> __init_end = .;
>
> .data :
> --
> 2.55.0
>
>
next prev parent reply other threads:[~2026-09-26 2:12 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-21 10:29 [PATCH] um: mprotect() __init memory Johannes Berg
2026-09-26 2:12 ` Hajime Tazaki [this message]
2026-09-26 9:16 ` Johannes Berg
2026-09-28 7:33 ` Johannes Berg
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m24ifc4v6m.wl-thehajime@gmail.com \
--to=thehajime@gmail.com \
--cc=johannes.berg@intel.com \
--cc=johannes@sipsolutions.net \
--cc=linux-um@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox