From: Johannes Berg <johannes@sipsolutions.net>
To: Tiwei Bie <tiwei.bie@linux.dev>,
richard@nod.at, anton.ivanov@cambridgegreys.com
Cc: linux-um@lists.infradead.org, tiwei.btw@antgroup.com
Subject: Re: [PATCH v2 3/3] um: Stop tracking stub's PID via userspace_pid[]
Date: Fri, 11 Jul 2025 09:03:26 +0200 [thread overview]
Message-ID: <7dec916560a07a6d9d3f8e37bae482738d2c360c.camel@sipsolutions.net> (raw)
In-Reply-To: <20250711065021.2535362-4-tiwei.bie@linux.dev> (sfid-20250711_085106_929511_67CD6311)
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():
> 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?
johannes
next prev parent reply other threads:[~2025-07-11 7:03 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 [this message]
2025-07-11 12:28 ` Tiwei Bie
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=7dec916560a07a6d9d3f8e37bae482738d2c360c.camel@sipsolutions.net \
--to=johannes@sipsolutions.net \
--cc=anton.ivanov@cambridgegreys.com \
--cc=linux-um@lists.infradead.org \
--cc=richard@nod.at \
--cc=tiwei.bie@linux.dev \
--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).