public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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>
Subject: Re: [PATCH] kthread: Rename user_mode_thread() to kmuser_thread()
Date: Tue, 12 Sep 2023 12:29:37 -0500	[thread overview]
Message-ID: <87a5tr1eri.fsf@email.froward.int.ebiederm.org> (raw)
In-Reply-To: <CAAhV-H7D85NTS+8VP6ELiiMVrFkarhjBFbHERLbA9azaK9=XcQ@mail.gmail.com> (Huacai Chen's message of "Tue, 12 Sep 2023 23:31:12 +0800")

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

  reply	other threads:[~2023-09-12 17:30 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-15 12:10 [PATCH] kthread: Rename user_mode_thread() to kmuser_thread() Huacai Chen
2023-06-25  8:55 ` Huacai Chen
2023-06-30 23:25   ` Luis Chamberlain
2023-07-18 12:43     ` Huacai Chen
2023-07-23 14:13       ` Huacai Chen
2023-09-11 12:07         ` Huacai Chen
2023-09-12  1:58           ` Eric W. Biederman
2023-09-12 15:31             ` Huacai Chen
2023-09-12 17:29               ` Eric W. Biederman [this message]
2023-09-13 12:39                 ` Huacai Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a5tr1eri.fsf@email.froward.int.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=chenhuacai@kernel.org \
    --cc=chenhuacai@loongson.cn \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mcgrof@kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox