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 kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 419ECC7EE22 for ; Mon, 15 May 2023 14:42:53 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C763D900005; Mon, 15 May 2023 10:42:52 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id C26BD900004; Mon, 15 May 2023 10:42:52 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AC81E900005; Mon, 15 May 2023 10:42:52 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 9E608900004 for ; Mon, 15 May 2023 10:42:52 -0400 (EDT) Received: from smtpin17.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id 6FAD51412FE for ; Mon, 15 May 2023 14:42:52 +0000 (UTC) X-FDA: 80792756184.17.9246535 Received: from out03.mta.xmission.com (out03.mta.xmission.com [166.70.13.233]) by imf24.hostedemail.com (Postfix) with ESMTP id C1F5A180007 for ; Mon, 15 May 2023 14:42:49 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684161770; a=rsa-sha256; cv=none; b=PgtEieiJEluHdsdtmGuSOONHlQhaCAUYA0QEdgly8j/u7uDaE+wEo6E9Y7A2/rSY6gBGT2 1GUxQcQes1/wU7JQX6sgKXR8TzAkGxVNy6GeyItheAdZ2Dc9d/r14jN+2kQlPiMk2MDbKj FcUQuCc56kwqQXM1Y/bLBu8eK41GBaI= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=none; spf=pass (imf24.hostedemail.com: domain of ebiederm@xmission.com designates 166.70.13.233 as permitted sender) smtp.mailfrom=ebiederm@xmission.com; dmarc=pass (policy=none) header.from=xmission.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684161770; 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-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=X9ga0kZkL1CdxihirTFJ5Ui3WJsnG5diFlPbEVm+1lc=; b=wxOVAj91UOqKNdRsJeU+XRjp8W4Po5urHtNi0t552eL8LRvcuyqGoImj7v98TAx0BbrhLp chkVlImjWBNNQljt/RcZoUpYJfQoWmEoL1AFB693lSudeFsuHigHEaztl4vvnlwZCNkUof fbzGNzesDggJpqutPz7P4xgsWB/2Dto= Received: from in02.mta.xmission.com ([166.70.13.52]:41028) by out03.mta.xmission.com with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1pyZPT-000HU2-Ep; Mon, 15 May 2023 08:42:47 -0600 Received: from ip68-110-29-46.om.om.cox.net ([68.110.29.46]:48662 helo=email.froward.int.ebiederm.org.xmission.com) by in02.mta.xmission.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.93) (envelope-from ) id 1pyZPR-003Kxl-OI; Mon, 15 May 2023 08:42:47 -0600 From: "Eric W. Biederman" To: Huacai Chen Cc: Huacai Chen , Luis Chamberlain , Andrew Morton , Kees Cook , linux-mm@kvack.org, linux-kernel@vger.kernel.org In-Reply-To: (Huacai Chen's message of "Sat, 13 May 2023 11:18:37 +0800") References: <20230509104127.1997562-1-chenhuacai@loongson.cn> <87ild0w5qs.fsf@email.froward.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux) Date: Mon, 15 May 2023 09:41:50 -0500 Message-ID: <87ttwdu05t.fsf@email.froward.int.ebiederm.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-XM-SPF: eid=1pyZPR-003Kxl-OI;;;mid=<87ttwdu05t.fsf@email.froward.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=68.110.29.46;;;frm=ebiederm@xmission.com;;;spf=pass X-XM-AID: U2FsdGVkX18kmDAXAFN2evKbBlpraJSCti1ihQ0mM6I= X-SA-Exim-Connect-IP: 68.110.29.46 X-SA-Exim-Mail-From: ebiederm@xmission.com Subject: Re: [PATCH RFC] kthread: Unify kernel_thread() and user_mode_thread() X-SA-Exim-Version: 4.2.1 (built Sat, 08 Feb 2020 21:53:50 +0000) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) X-Rspam-User: X-Stat-Signature: f713mpxuf8kkhd3xhnimrzxaditaq9gg X-Rspamd-Server: rspam08 X-Rspamd-Queue-Id: C1F5A180007 X-HE-Tag: 1684161769-808578 X-HE-Meta: U2FsdGVkX1/X2U6kATiYKh/M6hEAjmv1VMOgOKNIUv4Wbq0fcyzdaUi7wBI9RCzOfa+DOheKmreIlGYwtIbUjETrdflUW2n0nlZ9ehWURyv+SssEPzxUnl0qRDb8rOfVc+sWCWK+ann+9YATLSsDZAN+CXsBzPOklpSqG8ZJChFg6Z6h/2IuulEylmBCm7IE/jdoNzZO3MmjigWv5xInW7nkNvbDM3yNFnj7p4+l3yboHBxwnLWCG/W9p0HmxO5lz7bqRk5z8zX8uTp9xdZuCTmRSUB5J6ISTp28TJjl1KIq2k9DX1x4F3Kl205JlwlQhxhX5sHdiwm8Y+07hCTKzJQa2dxUcEmdGvailVaNeoO6iUXCKcvjuqM/Gay43hsOO2YrD5Pq1lV1pLfEnT5VTUUeHAlT1aPkgJmHnjQ9/zCBuSPrNRIOGRGAkM16wQBHf7j4n53hT7FssJdAUhL3YaBYyPAv6/+uTa+QvrL4Z/606GkaBU4p46wu4KVFPxTZ8j1MZ2JoGoOds3B2uh0wkeueY+tzr3hdzXAAZ4PwnIgVTjAz/zUv+MchYbSkRQ4pETmPbYnYagVxNO5IQr3rZIBbQUlSYTJ95zkg0VHSlNRJRzx1+sQs+KwG9PgGLo2feY70LGsPuWLtLUhXD8FZapZ9u1/qVic+MGienbFYtyasMcENBfLjuwYlwZzqg03NJ3SJyGtETMX2rJubXVr/+QcJjOHfnOsUaNxpCQXRWSOF8oeFLgWACwX0swmapehCyLvzzQutz7NdnT/Lu++1XT3f6QdfTYELAjYW6X6f6XeA6mbm0mMMUXgy6Vz8knmp6LBXPF3c2IGEFuwI/V9vhxLgQFIkLMW4o/9g+duhw0UFFkD8lw7ZGYjKgJ6EgXSoAY/MiVhy2A7fO038en5YSwfMVLQWxhzmuzU6lgoPXNn3DU+wxf+c2QUvNJV0AxKKgrhadgjhyCP/IQ3HmIw JCmpXAxk da0S7KzcQ86pbuoR/C8xhywfaKJciMaHO2XlmchIrFdcYEWP4IRc6KGEN6Ho+wGy7nYJRzgVq5bVzutCfpjMIxALXt5NnhzaEConvRi5VfmsD1sGTtBfekVSWsRJnq2vdK58La6GoDCDAUkybTcmKAmOyjOKPHV+QpZor1ujB8Y3DBxP8aJUkZ40Fju+wQK2ezgq7rrZlA3GKnBUHdSftuWB6kKnimojavbxD5gJPTsjtG9w= 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: Huacai Chen writes: > Hi, Eric, > > On Wed, May 10, 2023 at 11:45=E2=80=AFPM Eric W. Biederman > wrote: >> >> Huacai Chen writes: >> >> > Commit 343f4c49f2438d8 ("kthread: Don't allocate kthread_struct for in= it >> > and umh") introduces a new function user_mode_thread() for init and um= h. >> > But the name is a bit confusing because init and umh are indeed kernel >> > threads at creation time, the real difference is "they will become user >> > processes". >> >> No they are not "kernel threads" at creation time. At creation time >> init and umh are threads running in the kernel. >> >> It is a very important distinction and you are loosing it. >> >> Because they don't have a kthread_struct such tasks in the kernel >> are not allowed to depend on anything that is ``kthread''. > Hmm, traditionally, we call a "task" without userland address space > (i.e., the task_struct has no mm, it shares kernel's address space) as > a kernel thread, so init and umh are kernel threads until they call > kernel_execve(). No. The important distinction is not the userland address space. The important distinction is how such tasks interact with the rest of the system. It is true the mm does not initially have userspace content but that does not change the fact that it is a valid userspace mm. For scheduling, for signal delivery, and for everything else these tasks are userspace tasks. The very important detail is that it is not at kernel_execve time that the distinction is made, but that it is made earlier when the thread is created. This is a subtle change from the way things used to work once upon a time. But the way things used to work was buggy and racy. Deciding at thread creation time what the thread will be used for, what limitations etc is much less error prone. We had this concept of kthread_create that used to create a special class of tasks. What was special, and what extra could be done with those tasks was defined by the presence "struct kthread" (my apologies I mispoke when I said kthread_struct earlier). Then because that specialness was needed on other tasks struct kthread started to be added to tasks at run-time. That runtime addition of struct kthread introduced races that complicated the code, and had bugs. > Of course in your patch a kernel thread should have a > "kthread" struct (I can't grep "kthread_struct" so I suppose you are > saying "kthread"), but I think the traditional definition is more > natural for most people? Natural and traditional is a silly argument. The fact is those are tasks that ultimately run userspace code. That ability needs to be decided upon at creation time to make them race free. Therefore the old code and definition are wrong. Eric