From patchwork Thu Jun 15 12:10:16 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Huacai Chen X-Patchwork-Id: 13281111 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id E6FCAEB64DC for ; Thu, 15 Jun 2023 12:10:39 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 743846B0072; Thu, 15 Jun 2023 08:10:39 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6F4328E0003; Thu, 15 Jun 2023 08:10:39 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5BC8D8E0002; Thu, 15 Jun 2023 08:10:39 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 4D88D6B0072 for ; Thu, 15 Jun 2023 08:10:39 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 28C79A0880 for ; Thu, 15 Jun 2023 12:10:39 +0000 (UTC) X-FDA: 80904865398.08.4451DF6 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf05.hostedemail.com (Postfix) with ESMTP id 53207100006 for ; Thu, 15 Jun 2023 12:10:36 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of "SRS0=5KbI=CD=loongson.cn=chenhuacai@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=5KbI=CD=loongson.cn=chenhuacai@kernel.org"; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1686831037; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-transfer-encoding:content-transfer-encoding: in-reply-to:references; bh=dbz5Vt7jk+Bc4opi80VNcivt0MabGypC+A8sLMbJm9s=; b=rjMjMKBDxjcHfqCFqeaU2B4GdVb9YlON5WaGdNNVwXq+HJW2wXqn/pCWVKnIOrtCwSXxGe S8gYMppEm9QgovCEIysC6rOoCNJuFrvNvOqFnGePRK/Ux0shsWVmtfzjc1wn/OUZQaodFj 7ZdYfQd9Wrzp6r+4bgXEpGBs31iXelY= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1686831037; a=rsa-sha256; cv=none; b=hUzim/9NvWJrQ7iFuKC8Tt2qeToElxBEIPlejQkn7Puqwm27I7n0iQKmkOo4MsBU+CJwB2 GW+b/NF5JVqjWR4LvI34L1BumX04vVtuIYusNdCK9z57e89AeywnWxOL5hKSGefHP0utqy hoK8XA9MRiiVcnWT6l1nSTi7OGpotYI= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=none; spf=pass (imf05.hostedemail.com: domain of "SRS0=5KbI=CD=loongson.cn=chenhuacai@kernel.org" designates 139.178.84.217 as permitted sender) smtp.mailfrom="SRS0=5KbI=CD=loongson.cn=chenhuacai@kernel.org"; dmarc=none Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 4861F61E48; Thu, 15 Jun 2023 12:10:36 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 97596C433C8; Thu, 15 Jun 2023 12:10:33 +0000 (UTC) From: Huacai Chen To: Luis Chamberlain , Andrew Morton , "Eric W . Biederman" Cc: Kees Cook , chenhuacai@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Huacai Chen Subject: [PATCH] kthread: Rename user_mode_thread() to kmuser_thread() Date: Thu, 15 Jun 2023 20:10:16 +0800 Message-Id: <20230615121016.3731983-1-chenhuacai@loongson.cn> X-Mailer: git-send-email 2.39.3 MIME-Version: 1.0 X-Rspamd-Queue-Id: 53207100006 X-Rspam-User: X-Stat-Signature: mqb8q8b95msi7ronjjzxi6okeac3sjqo X-Rspamd-Server: rspam03 X-HE-Tag: 1686831036-872860 X-HE-Meta: U2FsdGVkX1/Q1LF/bk9MWAN4EEzW8MNzPNTLPioaWt0zcjRIaVxMMklIZE2pFbWkHl/REZ02oGLhpX8IYJFEzvs9ALLwbzt0m7EYocHWQDrD8H824HQIj8js0MN6XWHY4h5ZS84jOVZzLb8OmERWXWeTfZZlg1vc/8l16W++vCISs3NebgSaC5Vi2ec+fc8NQtXiAZdaaBc8lEz4V+Z6zZ5UA/ac/hqzADAMZp27urGDuVu/SsFZEDoxBkQK1k/rG5gNXoIVwpU3IkDA1rpEbkxZ2Rgo+PPzXODmc9VZ7W9S/2RyzLwgvIbaVDdAWVXJy2q8iZePUgowW72q+1hDjhwSJ49o0qVq7p05bZjOHx5zauW/ABYsLXn79toyQOdLhKX0RLxRjmTwC6Qx4sjhDCQ/Xmjzct7CK9KlP2bIIOwz/ojPuaZ7fy2IN/s24LcKGjpcqKnWoDHxQTUpbQA5JOsGPepoQYOf4YSy8BgGiOqwHOCiTomCL8uw6CMCBH6uijGpgIh4sswTFHV2Z8n8z39NgsxF6eHsncEzF1IcOAw2QLwVCCCqN+xXYZCHjfvDIz4Gi+LAFryQ0tqFQyBHIynI8l3dTg34SKb5HjBYIjUVwj7iGW2KnYTNxHdujpgFolQH76Pkm67GExP8PGZNa/pq9A2pYsMJsQ4xCWRrW5Iu3L5s+a1+gMPeAC0iR3kAOiWS1TSoC/DkZUVFHQYdEQS1RjbXxNhLXWIbnwAegPOLZRfvvIl4u2zJ8jw8ctzZDatxJP11SxOQBcX5rzasjJY9kutPavDrey7GX+Y3PT4JqAA5dH2hPqcdVi3cbEj+C/vV3vlfkYroCo69VuaNwhszP1oBQF2n81S57HdLXfAICHhY65vMe1nNbLY+oB9msJNzoqPAU/LFZX3ImhxAyIrbFJtdn0iBHmuuaf+vBytMXFBiPsBLhVpSFnQGwnZwIWvhXCntpLxtbzU0mDY SclsUrK+ mER2ywZQp8A8eCTen6TY7q/bbMUM3K6STtvHRx2LXTC8vossp9bmfS2O9qpblZALkaPUD6VXmpeuzlHDiPq+3eQLZKcOZCTlUx4uXyrOkmy1kvrw56Nl0fO31YFqST3PFMa7dfD8sN011AYrps8TxUvCiNqDV3o3gwTqEKxxeXM08xtN2TtmML+5MNj1tZBry+dGp1JjeIScrYtK86VvG4/DAKq2eP0jdZP5WObr1KXClyYDTcLMVKOyzms2ZZWrpgpX9Wxm7Eu3Y9NQXxAQi0zPTsNU026eiL0bwsYdZMnXfrR0fncm/sqWHzlKGrWOP8CynMN3mWlVJVWov4YfDp8AmDE4jqjWWaOKWARamrAbznVdKEc2rY6ngoLbPZNTXg8nIEPI1jI9l93s0ursAvF5abz+g+XLIfa1Ggcy3xmIYUaC87LvQTFZ/SLbq1deyFFoe X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: 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 --- 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;