Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   "Eric W. Biederman" <ebiederm@xmission.com>
To:     Huacai Chen <chenhuacai@kernel.org>
Cc:     Luis Chamberlain <mcgrof@kernel.org>,
        Huacai Chen <chenhuacai@loongson.cn>,
        Andrew Morton <akpm@linux-foundation.org>,
        Kees Cook <keescook@chromium.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org, Thomas Gleixner <tglx@linutronix.de>
In-Reply-To: <CAAhV-H5pwHQTQ6wGXC2NELHmC4JM8rQUViR3RJj8hQLBygb00w@mail.gmail.com>
        (Huacai Chen's message of "Mon, 11 Sep 2023 20:07:55 +0800")
References: <20230615121016.3731983-1-chenhuacai@loongson.cn>
        <CAAhV-H49AyrG-sH2SXLNg_cX-Wv8vS4Qno_2N4v6ccGGciv-+A@mail.gmail.com>
        <ZJ9kWqhRCWkLcYyv@bombadil.infradead.org>
        <CAAhV-H7qk8wSFt=ZMUSUt4cAmH+-5AsGqszXNW9w+u6Y8vDN+A@mail.gmail.com>
        <CAAhV-H7RgkZJ2hfmNmJXKqcYeE1q11V4-2Ni0j-FLJ0b5fc=Sg@mail.gmail.com>
        <CAAhV-H5pwHQTQ6wGXC2NELHmC4JM8rQUViR3RJj8hQLBygb00w@mail.gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Date:   Mon, 11 Sep 2023 20:58:52 -0500
Message-ID: <87cyyo9moz.fsf@email.froward.int.ebiederm.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8BIT
Subject: Re: [PATCH] kthread: Rename user_mode_thread() to kmuser_thread()
Precedence: bulk

Huacai Chen <chenhuacai@kernel.org> writes:

> Hi, all,
>
> Friendly ping again?
>
>
> Huacai
>
> On Sun, Jul 23, 2023 at 10:13 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>>
>> Hi, Eric,
>>
>> On Tue, Jul 18, 2023 at 8:43 PM Huacai Chen <chenhuacai@kernel.org> wrote:
>> >
>> > Hi, Luis,
>> >
>> > On Sat, Jul 1, 2023 at 7:25 AM Luis Chamberlain <mcgrof@kernel.org> wrote:
>> > >
>> > > On Sun, Jun 25, 2023 at 04:55:33PM +0800, Huacai Chen wrote:
>> > > > Friendly ping?
>> > >
>> > > You want to cc the folks who Nacked your patch. Until then, this
>> > > probably can't go further.
>> > Thank you very much. Eric and Andrew are already in the CC list, so
>> > add Thomas now.
>> >
>> > My brain is a little old-fashioned so I insisted that "a thread
>> > without mm_struct should be a kernel thread" in the previous patch.
>> > Unfortunately this makes Eric and Thomas unhappy, I'm very sorry for
>> > that.
>> >
>> > During the discussion of the previous patch I know I made some
>> > mistakes about some basic concepts, but I also found the name
>> > "user_mode_thread()" is somewhat confusing. I think rename it to
>> > kmuser_thread() is better, because:
>> > 1, it identify init and umh as user threads;
>> > 2, it points out that init and umh are special user threads that run
>> > in kernel mode before loading a user program.
>> >
>> > Sorry for my rudeness again.
>> Excuse me, but could you please tell me what your opinion is. In my
>> opinion a typical user thread is created by
>> pthread_create()/sys_clone(), it is better to distinguish typical user
>> threads from init and umh.

If we want to emphasize that it is a kernel concept I am happy with
renaming user_mode_thread to user_mode_task.  That is more accurate.

But all threads from the kernel perspective are tasks.  Further
all threads have times when they run code in the kernel (aka system
calls) and times when they run code in userspace.

Linux kernel tasks created with user_mode_thread() are exactly like
other user mode tasks, and have all treated exactly the same was by the
system as any the tasks created by pthread_create() and sys_clone().

The only oddity is that there is no user mode code to execute until
after execve is called.

When running code in the kernel, user space threads never logically
do not use the user space page tables.

They are different in some significant ways from tasks created with
kernel_thread().  Tasks created with kernel_thread do not support
calling execve, among other things.

But deeply and fundamentally I think you are trying to make a
distinction that is not there.  All user space threads run code
in the kernel before they run code in userspace.  Most often
it is from the system calls fork/clone/exec.  For init and umh it
is effectively a special dedicated system call that includes
an execve.

Let me ask what difference are you trying to high light that callers
of user_mode_thread need to be aware of?  What problem in thinking
do you think that the name user_mode_thread creates?  I am asking
because I might just be missing your point.

Eric