linux-um.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Tiwei Bie <tiwei.bie@linux.dev>
To: johannes@sipsolutions.net
Cc: richard@nod.at, anton.ivanov@cambridgegreys.com,
	linux-um@lists.infradead.org, tiwei.bie@linux.dev,
	tiwei.btw@antgroup.com
Subject: Re: [PATCH v2 3/3] um: Stop tracking stub's PID via userspace_pid[]
Date: Fri, 11 Jul 2025 20:28:19 +0800	[thread overview]
Message-ID: <20250711122819.2727024-1-tiwei.bie@linux.dev> (raw)
In-Reply-To: <7dec916560a07a6d9d3f8e37bae482738d2c360c.camel@sipsolutions.net>

On Fri, 11 Jul 2025 09:03:26 +0200, Johannes Berg wrote:
> On Fri, 2025-07-11 at 14:50 +0800, Tiwei Bie wrote:
> > From: Tiwei Bie <tiwei.btw@antgroup.com>
> > 
> > The PID of the stub process can be obtained from current_mm_id().
> > There is no need to track it via userspace_pid[]. Stop doing that
> > to simplify the code.
> 
> So that is really obvious cleanups, and I can go apply them on that
> grounds, but I started wondering if we're not separately being
> inconsistent here, which perhaps didn't matter due to non-SMP:
> 
> >  #define activate_mm activate_mm
> >  static inline void activate_mm(struct mm_struct *old, struct mm_struct *new)
> >  {
> > -	/*
> > -	 * This is called by fs/exec.c and sys_unshare()
> > -	 * when the new ->mm is used for the first time.
> > -	 */
> > -	__switch_mm(&new->context.id);
> >  }
> 
> This is now empty, so I wondered if we can just remove it _entirely_.
> 
> But the generic version calls switch_mm():

Yeah, removing activate_mm() will cause it to call switch_mm(). This is
somewhat a behavior change beyond the scope of this patchset, so I kept
it as is.

>  
> >  static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, 
> > @@ -28,11 +23,9 @@ static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next,
> >  {
> >  	unsigned cpu = smp_processor_id();
> >  
> > -	if(prev != next){
> > +	if (prev != next) {
> >  		cpumask_clear_cpu(cpu, mm_cpumask(prev));
> >  		cpumask_set_cpu(cpu, mm_cpumask(next));
> > -		if(next != &init_mm)
> > -			__switch_mm(&next->context.id);
> >  	}
> >  }
> 
> which plays with the CPU mask, but realistically being non-SMP the CPU
> mask is never really used?
> 
> Certainly removing activate_mm() entirely seems to _work_, but of course
> it never does anything since smp_processor_id() eventually is just
> macros that expand to "0" (unless preempt debug is enabled). Any
> thoughts?

Yeah, things are a bit messy here and need to be sorted out.

IIUC, activate_mm() and switch_mm() are primarily used to update the
page table and manage the TLBs on the CPU for each user address space.
However, in UML, each user address space is represented by a separate
stub process, and the host kernel already takes care of that. So, I'm
not entirely sure why we need to maintain the mm_cpumask. Perhaps we
could just do this:

--- a/arch/um/include/asm/mmu_context.h
+++ b/arch/um/include/asm/mmu_context.h
@@ -13,20 +13,9 @@
 #include <asm/mm_hooks.h>
 #include <asm/mmu.h>
 
-#define activate_mm activate_mm
-static inline void activate_mm(struct mm_struct *old, struct mm_struct *new)
-{
-}
-
 static inline void switch_mm(struct mm_struct *prev, struct mm_struct *next, 
 			     struct task_struct *tsk)
 {
-	unsigned cpu = smp_processor_id();
-
-	if (prev != next) {
-		cpumask_clear_cpu(cpu, mm_cpumask(prev));
-		cpumask_set_cpu(cpu, mm_cpumask(next));
-	}
 }
 
 #define init_new_context init_new_context

Regards,
Tiwei


      reply	other threads:[~2025-07-11 12:30 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-07-11  6:50 [PATCH v2 0/3] um: Remove userspace_pid[] Tiwei Bie
2025-07-11  6:50 ` [PATCH v2 1/3] um: Use err consistently in userspace() Tiwei Bie
2025-07-11  6:50 ` [PATCH v2 2/3] um: Remove the pid parameter of handle_trap() Tiwei Bie
2025-07-11  6:50 ` [PATCH v2 3/3] um: Stop tracking stub's PID via userspace_pid[] Tiwei Bie
2025-07-11  7:03   ` Johannes Berg
2025-07-11 12:28     ` Tiwei Bie [this message]

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=20250711122819.2727024-1-tiwei.bie@linux.dev \
    --to=tiwei.bie@linux.dev \
    --cc=anton.ivanov@cambridgegreys.com \
    --cc=johannes@sipsolutions.net \
    --cc=linux-um@lists.infradead.org \
    --cc=richard@nod.at \
    --cc=tiwei.btw@antgroup.com \
    /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;
as well as URLs for NNTP newsgroup(s).