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 AF7D1C77B7A for ; Sat, 20 May 2023 08:50:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id D6B63900005; Sat, 20 May 2023 04:50:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id D1B67900003; Sat, 20 May 2023 04:50:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id BE2A5900005; Sat, 20 May 2023 04:50:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id AC025900003 for ; Sat, 20 May 2023 04:50:24 -0400 (EDT) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 6A5B4C0B2B for ; Sat, 20 May 2023 08:50:24 +0000 (UTC) X-FDA: 80810011968.15.BDFFF99 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id 75B5E140009 for ; Sat, 20 May 2023 08:50:22 +0000 (UTC) Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JyxMp5y9; spf=pass (imf23.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=none) header.from=kernel.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1684572622; 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:dkim-signature; bh=HKhh5gDjc6NNKrhhGsdA550njbtO12XiVWeO2j/F4u4=; b=MA05SfDZRH3ayXfCMlFtzmg9DEDk6/VNt3lumzezv3uLhZRm1zX8bQCY0+VtRUhv8bHFuP 7SRVcz5e2Nk9+9mZTgh8nQFvpfcABbZZgH24fDgeVNHkdScH6ZMwzl95OmmJvJczj2LfvX IhfSI9MyAvT6OHbUW2ka3pd30sRFAJU= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1684572622; a=rsa-sha256; cv=none; b=6lCAZvyYaf7edh+NkE90NUBMOzoezWWS7qGLn/H75qrwwGApbYtgjnV4WsSauc+WocAtQg wZtufQR8YfjlXNmlsY0pPqCsurSBME+GXxtm1WUNFCgZLXp83ZSyuAS2ecdBlyj35CCcLq 69MBe75ELYvMBmiSoLvedvyr4h3+iR4= ARC-Authentication-Results: i=1; imf23.hostedemail.com; dkim=pass header.d=kernel.org header.s=k20201202 header.b=JyxMp5y9; spf=pass (imf23.hostedemail.com: domain of chenhuacai@kernel.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=chenhuacai@kernel.org; dmarc=pass (policy=none) header.from=kernel.org 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 56E1A6090A for ; Sat, 20 May 2023 08:50:21 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id B61C7C433D2 for ; Sat, 20 May 2023 08:50:20 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1684572620; bh=X/AwhdFPPERYtbQ7sS7+eyBw3xKrtCMibi3UUYr5J2E=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=JyxMp5y95aZzCB0cvBvYssg2uZLhqMGIsPVRwwpxz1a5FS7KIdMXflxI8c1bfp7SC +t42OmVcNXci82J9u+B17a2ktWnYmBncD5Ez2g+52fpICwlcm/v9kkv70IywYRVig3 nzxBA/geFHcaiEWErEyKc7VaTKQ+vYAXvNUYJNcEFXftFijH+RjDqzLnjLiicMnVkr L/+QOToR5c/8DnCl3Wv5F0+sCBKLa8fR7FfHKK7y6hQdPW4mQPojRp2LbQq/imqXO2 HfRc4vm8PiHtNZYgJSlkt1LsWebphOKkcQDnHj3h+MjZtIxIi6I2e0P1Qj21jlzzwj ZJpTM6b0Th6Qg== Received: by mail-ej1-f47.google.com with SMTP id a640c23a62f3a-96f50e26b8bso403698666b.2 for ; Sat, 20 May 2023 01:50:20 -0700 (PDT) X-Gm-Message-State: AC+VfDxL6R2dSwFWeesiVLrd4n7owyIehk7Uqhfc7uDlnpXVQOIVfi5g ogPqkcuRrBU6nLxxe89WQi2LZHu30PeMk+t7jaU= X-Google-Smtp-Source: ACHHUZ7B2eILcWdrKNoLYc4hTPaMPAOYvEKVM9MOKBsZcErc+TMFAnu+ATvDwsy0HjPQ0iiCU73v07I+GPZScFpzYAU= X-Received: by 2002:a17:907:c14:b0:969:e304:7a22 with SMTP id ga20-20020a1709070c1400b00969e3047a22mr5074698ejc.18.1684572619005; Sat, 20 May 2023 01:50:19 -0700 (PDT) MIME-Version: 1.0 References: <20230509104127.1997562-1-chenhuacai@loongson.cn> <87ild0w5qs.fsf@email.froward.int.ebiederm.org> <87ttwdu05t.fsf@email.froward.int.ebiederm.org> In-Reply-To: <87ttwdu05t.fsf@email.froward.int.ebiederm.org> From: Huacai Chen Date: Sat, 20 May 2023 16:50:07 +0800 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH RFC] kthread: Unify kernel_thread() and user_mode_thread() To: "Eric W. Biederman" Cc: Huacai Chen , Luis Chamberlain , Andrew Morton , Kees Cook , linux-mm@kvack.org, linux-kernel@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 75B5E140009 X-Rspam-User: X-Stat-Signature: t74ar11hkr9sjt39fy3fjnter6j9zu93 X-Rspamd-Server: rspam03 X-HE-Tag: 1684572622-510058 X-HE-Meta: U2FsdGVkX18zEwe7kCPDXVHS0bXRGDgjXh7EDPk+5dIEn6QV+AUaoP+FRNZnys/rFQFObdJ7OOBCk4Uh4BaBHBnU/XDajjay8qH9k/t1ihFPlLJCTLnnaWRgw+Y9NEA/gAnklw91PYe40F8cPvUXtLw/CLCYsjmKXG6C9z2poaGoy74EO4RzVKQTjsVCSkHE35MtXsLr6DkXh1nXg2yyfI9KGY8UY2Ctq9+iYt0akwU5Kk/q0ZI/Y+zk4yQdzng0fvoW/VbBUsFLmyVv8bZ5GLxyP3UPy1dnbx8QnChRAQnH8o29TX8v6VR1AjmvmwH0KAyNIiqG8Dt7xeIc/DWi7Ax7VKT6DqKmv275TIRLgByiPdxR8K08bNX3Dq3tZpm1YRVqDi28LeL5NAPeXb7uo7MFa/fjG4YDS7Mh2PYLfT+vvc3Giq1KQrdSgGrWruGu1w8CCspXcBVuEDmoMpNAw5JBZ6uIIwag9PAKNhXFqFBq2WXr6YAckMMcBXIWyobJ978xazKfNg7kAOY7SqiOAYvFuJaci09xWZPZlfrAVkQjr7IoLFI1Pp6dIO8CRSvaKeRoyjUe3jYUCIOhOfYO0PT/6GnoA1zK3ZONtyq9MgQYPCSdUNpY+PsyiIkDOCG+9yb00p18A2gGNVVf5Uo6VZGyt8v+wl1Oe24DNX+7teQMBuNI7WROXLqiZfXeS9UshD95SdbNy1PpXxwyTew+nIdnY1OrmxOSs1KP7Am56BRZOiYhKrQoTqeN4afYlC55FPBBY/V9pNzx1OgZW7x4l14APIWU3jt1DQLcYbpy3Jf50AiDsuLiIGaV6c8SkPiGfdC66jySXOpEVi7/h2bVj4aGVCOrI/pa6ka4+ilPMwgKmCF2mR0KLsfn/6pEOghxwlU2WadrFlyPNgQ3h+2lJJR9DKP3GbpDb1zPzFbMnkbFUsX2kqC+Z8Y7enKPPHYEfzJww9skt2sRDsgyfke qatnfVxO x9HoCr7+vNFAzc0iv+B8QEEBJMtRSkZt8lIo3L9Jq/Z6+RVZIcBq+R7O3tgGIfTPijbeZXH9mIL88Net5lH41jtayrBt42LTd6v/iC1BUQLWpbO0nz3MVsG4EI4/gaWeMZulwGF48eKKE6SZbBOJSNVbzKIhY1cUFYUVTJzyaRFYYbhbEXFl1vyMmCQZZ9SSSiQYLz7Npsb8vz/TeuzNHcwBQ6AIicW46jt1Anjg6z0C7qTA4CDYR2aWR/eGc1g9O6yZrKHNNhnRaUYA+CmUnOCd0rd/Hec567fPDYmHvSFtSCcRzPzT1+XrdvKUoWm3ynSAr647fuinH8Kv6wpEIcsvgEnKP/Rusu24FYqt7zuOvItClNi8kA0ar+/wXlDinv6KOMblbzqbY7vCApubMEJhBRXAxQ7HhjI/NjET8MBu3WdwyOCS6jHQoHwSGgmfKgYakKbG3y23zZpqyZjSZxDKCeEXmOYP0/MuK 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: Hi, Eric, On Mon, May 15, 2023 at 10:42=E2=80=AFPM Eric W. Biederman wrote: > > 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 = init > >> > and umh") introduces a new function user_mode_thread() for init and = umh. > >> > But the name is a bit confusing because init and umh are indeed kern= el > >> > threads at creation time, the real difference is "they will become u= ser > >> > 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. Thank you very much for providing so much background information. Now I know that init and umh are different from typical kernel threads, but on the other hand, they are also different from typical user mode threads (have no mm struct at creation time). So from my point of view, we can treat them as "special kernel thread". Huacai > > > 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