All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hajime Tazaki <thehajime@gmail.com>
To: johannes@sipsolutions.net
Cc: linux-um@lists.infradead.org, johannes.berg@intel.com
Subject: Re: [RFC PATCH 8/9] um: nommu: add userspace runner processes
Date: Wed, 22 Jul 2026 10:30:16 +0900	[thread overview]
Message-ID: <m27bmn4xqv.wl-thehajime@gmail.com> (raw)
In-Reply-To: <20260720205103.5a666eac428b.I9f810f3ed177d6dc980cad36c231f8c745dee48f@changeid>


On Tue, 21 Jul 2026 03:26:58 +0900,
Johannes Berg wrote:
> 
> From: Johannes Berg <johannes.berg@intel.com>
> 
> For NOMMU there are not separate address spaces for
> each userspace process group, which on the one hand
> means we cannot start them on demand, but on the
> other means we can just have one for each (virtual)
> CPU, and map all of the memory into them.
> 
> Implement such processes, and the remaining bits
> needed to compile the kernel without CONFIG_MMU.

I was wondering where kernel address is located in this mode.

although it doesn't have to be, under nommu, kernel address is located
in the same address space with all userspace processes in my
understanding.

the kernel address is accessible (danger but it's !MMU) from userspace
thus __access_ok() always returns 1.  so just wondering what is the
case with this runner process approach.

a program accessing kernel address may fail (or crash in some case),
but with the runner it won't ?

-- Hajime


  reply	other threads:[~2026-07-22  1:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-20 18:26 [RFC PATCH 0/9] simplified UML/NOMMU approach Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 1/9] x86/um: nommu: elf loader for fdpic Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 2/9] um: decouple MMU specific code from the common part Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 3/9] um: nommu: memory handling Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 4/9] um: change machine name for uname output Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 5/9] x86/um/vdso: nommu: vdso memory update Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 6/9] um: further decouple MMU related code Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 7/9] um: nommu: add SMP futex operations Johannes Berg
2026-07-20 19:06   ` Johannes Berg
2026-07-20 19:10     ` Johannes Berg
2026-07-20 18:26 ` [RFC PATCH 8/9] um: nommu: add userspace runner processes Johannes Berg
2026-07-22  1:30   ` Hajime Tazaki [this message]
2026-07-20 18:26 ` [RFC PATCH 9/9] um: nommu: plug nommu code into build system Johannes Berg
2026-07-22  0:39 ` [RFC PATCH 0/9] simplified UML/NOMMU approach Hajime Tazaki
2026-07-22  7:46   ` 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=m27bmn4xqv.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.