Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.33 as permitted sender) client-ip=23.128.96.33;
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-H7D85NTS+8VP6ELiiMVrFkarhjBFbHERLbA9azaK9=XcQ@mail.gmail.com>
        (Huacai Chen's message of "Tue, 12 Sep 2023 23:31:12 +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>
        <87cyyo9moz.fsf@email.froward.int.ebiederm.org>
        <CAAhV-H7D85NTS+8VP6ELiiMVrFkarhjBFbHERLbA9azaK9=XcQ@mail.gmail.com>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Date:   Tue, 12 Sep 2023 12:29:37 -0500
Message-ID: <87a5tr1eri.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, Eric,
>
> On Tue, Sep 12, 2023 at 9:59 AM Eric W. Biederman <ebiederm@xmission.com> wrote:
>>
>> 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.
> 1, My first key point is “intuition”, by intuition
> sys_clone()/pthread_create() creates a user thread, but init and umh
> are more or less different (special user thread).

My point is the entire point of the name is to point out your intuition
is probably wrong in this context.

> 2, My second key point is "symmetry", for symmetry ‘kernel_thread’ is
> a counterpart of ‘user_thread’, while ‘user_mode_thread’ is a
> counterpart of ‘kernel_mode_thread’. If we keep the ‘kernel_thread’
> name, then we can only rename the ‘user_mode_thread’.

Frankly they could just as well be named user_mode_process,
and user_mode_task.  All are equally accurate.

kernel_thread is a bit different.  Strictly speaking they are all
processes that share the same address space.  But because they
all share the same address space and userspace can't touch them
thread is a perfectly adequate term.

> As discussed
> before, init and umh are user threads, but they are special user
> threads run in kernel mode before kernel_execve, so I want to rename
> it to ‘user_thread’ with a 'km' prefix, so ‘kmuser_thread’.

My deep and fundamental question to you is what technically makes umh
and init special?

What are you trying to point out to the rest of us with an improved
name?

I want to point out that people need to treat umh and init as user space
processes, and very much not as kernel threads.  That none of the
kernel_thread infrastructure works on them.

Eric