linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Huacai Chen <chenhuacai@loongson.cn>
To: Luis Chamberlain <mcgrof@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	"Eric W . Biederman" <ebiederm@xmission.com>
Cc: Kees Cook <keescook@chromium.org>,
	chenhuacai@kernel.org, linux-mm@kvack.org,
	linux-kernel@vger.kernel.org,
	Huacai Chen <chenhuacai@loongson.cn>
Subject: [PATCH] kthread: Rename user_mode_thread() to kmuser_thread()
Date: Thu, 15 Jun 2023 20:10:16 +0800	[thread overview]
Message-ID: <20230615121016.3731983-1-chenhuacai@loongson.cn> (raw)

Commit 343f4c49f2438d8 ("kthread: Don't allocate kthread_struct for init
and umh") introduces a new function user_mode_thread() for init and umh.

init and umh are different from typical kernel threads since the don't
need a "kthread" struct and they will finally become user processes by
calling kernel_execve(), but on the other hand, they are also different
from typical user mode threads (they have no "mm" structs at creation
time, which is traditionally used to distinguish a user thread and a
kernel thread).

In a former patch I treat init and umh as "special kernel threads" and
unify kernel_thread() and user_mode_thread() to kernel_thread() again.
However, the patch has been nacked because init and umh are essentially
"special user threads".

Nevertheless, I still agree with Andrews' comment "But the naming isn't
very good anyway. They should have been usermode_thread/kernel_thread or
user_thread/kernel_thread.".

Since Eric describes init and umh as "user threads run in kernel mode",
in this patch I rename user_mode_thread() as kmuser_thread(), which is
a little better than just user_thread().

Signed-off-by: Huacai Chen <chenhuacai@loongson.cn>
---
 include/linux/sched/task.h | 2 +-
 init/main.c                | 2 +-
 kernel/fork.c              | 4 ++--
 kernel/umh.c               | 4 ++--
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
index e0f5ac90a228..c774d604b0a3 100644
--- a/include/linux/sched/task.h
+++ b/include/linux/sched/task.h
@@ -98,7 +98,7 @@ struct task_struct *create_io_thread(int (*fn)(void *), void *arg, int node);
 struct task_struct *fork_idle(int);
 extern pid_t kernel_thread(int (*fn)(void *), void *arg, const char *name,
 			    unsigned long flags);
-extern pid_t user_mode_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern pid_t kmuser_thread(int (*fn)(void *), void *arg, unsigned long flags);
 extern long kernel_wait4(pid_t, int __user *, int, struct rusage *);
 int kernel_wait(pid_t pid, int *stat);
 
diff --git a/init/main.c b/init/main.c
index af50044deed5..362ba90d6f73 100644
--- a/init/main.c
+++ b/init/main.c
@@ -697,7 +697,7 @@ noinline void __ref __noreturn rest_init(void)
 	 * the init task will end up wanting to create kthreads, which, if
 	 * we schedule it before we create kthreadd, will OOPS.
 	 */
-	pid = user_mode_thread(kernel_init, NULL, CLONE_FS);
+	pid = kmuser_thread(kernel_init, NULL, CLONE_FS);
 	/*
 	 * Pin init on the boot CPU. Task migration is not properly working
 	 * until sched_init_smp() has been run. It will set the allowed
diff --git a/kernel/fork.c b/kernel/fork.c
index 41c964104b58..57d5c8c1766e 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2978,9 +2978,9 @@ pid_t kernel_thread(int (*fn)(void *), void *arg, const char *name,
 }
 
 /*
- * Create a user mode thread.
+ * Create a kernel mode user thread.
  */
-pid_t user_mode_thread(int (*fn)(void *), void *arg, unsigned long flags)
+pid_t kmuser_thread(int (*fn)(void *), void *arg, unsigned long flags)
 {
 	struct kernel_clone_args args = {
 		.flags		= ((lower_32_bits(flags) | CLONE_VM |
diff --git a/kernel/umh.c b/kernel/umh.c
index 60aa9e764a38..28c0cf0da7be 100644
--- a/kernel/umh.c
+++ b/kernel/umh.c
@@ -130,7 +130,7 @@ static void call_usermodehelper_exec_sync(struct subprocess_info *sub_info)
 
 	/* If SIGCLD is ignored do_wait won't populate the status. */
 	kernel_sigaction(SIGCHLD, SIG_DFL);
-	pid = user_mode_thread(call_usermodehelper_exec_async, sub_info, SIGCHLD);
+	pid = kmuser_thread(call_usermodehelper_exec_async, sub_info, SIGCHLD);
 	if (pid < 0)
 		sub_info->retval = pid;
 	else
@@ -169,7 +169,7 @@ static void call_usermodehelper_exec_work(struct work_struct *work)
 		 * want to pollute current->children, and we need a parent
 		 * that always ignores SIGCHLD to ensure auto-reaping.
 		 */
-		pid = user_mode_thread(call_usermodehelper_exec_async, sub_info,
+		pid = kmuser_thread(call_usermodehelper_exec_async, sub_info,
 				       CLONE_PARENT | SIGCHLD);
 		if (pid < 0) {
 			sub_info->retval = pid;
-- 
2.39.3



             reply	other threads:[~2023-06-15 12:10 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-15 12:10 Huacai Chen [this message]
2023-06-25  8:55 ` Huacai Chen
2023-06-30 23:25   ` Luis Chamberlain
2023-07-18 12:43     ` Huacai Chen
2023-07-23 14:13       ` Huacai Chen
2023-09-11 12:07         ` Huacai Chen
2023-09-12  1:58           ` Eric W. Biederman
2023-09-12 15:31             ` Huacai Chen
2023-09-12 17:29               ` Eric W. Biederman
2023-09-13 12:39                 ` Huacai Chen

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=20230615121016.3731983-1-chenhuacai@loongson.cn \
    --to=chenhuacai@loongson.cn \
    --cc=akpm@linux-foundation.org \
    --cc=chenhuacai@kernel.org \
    --cc=ebiederm@xmission.com \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcgrof@kernel.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