From mboxrd@z Thu Jan 1 00:00:00 1970 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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 89CA0C7EE24 for ; Mon, 5 Jun 2023 23:10:59 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232013AbjFEXK6 (ORCPT ); Mon, 5 Jun 2023 19:10:58 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49048 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231378AbjFEXKz (ORCPT ); Mon, 5 Jun 2023 19:10:55 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id B2891BE for ; Mon, 5 Jun 2023 16:10:54 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 3489A6227E for ; Mon, 5 Jun 2023 23:10:54 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 5715BC433EF; Mon, 5 Jun 2023 23:10:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1686006653; bh=lsPQl14SOHzCyq2ZcU8cv+2X6UzjCIK7sMnCYAcTMRw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=RzA2RZhaWfYhWC0ZlKJmz7T7oZMWQYPd8yOHDzwVgUI3+VBtWPZmdu1vNCoMS/Cgb 8FGSydi/jWKMpZ9tRtR9J+RGkpsbLIEjirzGds7UXKGomcM2H+UcoIISbzWG4IA+g1 rPLXCgnPihI7iIEhOCF7lRQd0UHrT/VvHlChyamA= Date: Mon, 5 Jun 2023 16:10:52 -0700 From: Andrew Morton To: Huacai Chen Cc: Luis Chamberlain , "Eric W . Biederman" , Kees Cook , chenhuacai@kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH V1] kthread: Unify kernel_thread() and user_mode_thread() Message-Id: <20230605161052.033ebe4cecc0a9c879d43f56@linux-foundation.org> In-Reply-To: <20230603015302.1768127-1-chenhuacai@loongson.cn> References: <20230603015302.1768127-1-chenhuacai@loongson.cn> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 3 Jun 2023 09:53:02 +0800 Huacai Chen wrote: > 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). > > So I think it is reasonable to treat init and umh as "special kernel > threads". Then let's unify the kernel_thread() and user_mode_thread() > to kernel_thread() again, and add a new 'user' parameter for init and > umh. > > This also makes code simpler. Seems fair enough. If we're attached to the naming then we could do static inline pid_t user_mode_thread(int (*fn)(void *), void *arg, unsigned long flags) { return __kernel_thread(fn, arg, flags, 0); } static inline pid_t kernel_thread(int (*fn)(void *), void *arg, unsigned long flags) { return __kernel_thread(fn, arg, flags, 1); } (and pass the 4th arg straight into .kthread to avoid the !user thing) But the naming isn't very good anyway. Should have been usermode_thread/kernel_thread or user_thread/kernel_thread.