Message-ID: <CAAhV-H5dZGBP51_TZbewCgsXs8XyCQsnus9gQde1SayP=zcHUQ@mail.gmail.com>
Date:   Wed, 13 Sep 2023 20:39:58 +0800
From:   Huacai Chen <chenhuacai@...nel.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Luis Chamberlain <mcgrof@...nel.org>,
        Huacai Chen <chenhuacai@...ngson.cn>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Kees Cook <keescook@...omium.org>, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org, Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] kthread: Rename user_mode_thread() to kmuser_thread()

Hi, Eric,

On Wed, Sep 13, 2023 at 1:30 AM Eric W. Biederman <ebiederm@...ssion.com> wrote:
>
> Huacai Chen <chenhuacai@...nel.org> writes:
>
> > Hi, Eric,
> >
> > On Tue, Sep 12, 2023 at 9:59 AM Eric W. Biederman <ebiederm@...ssion.com> wrote:
> >>
> >> Huacai Chen <chenhuacai@...nel.org> writes:
> >>
> >> > Hi, all,
> >> >
> >> > Friendly ping again?
> >> >
> >> >
> >> > Huacai
> >> >
> >> > On Sun, Jul 23, 2023 at 10:13 PM Huacai Chen <chenhuacai@...nel.org> wrote:
> >> >>
> >> >> Hi, Eric,
> >> >>
> >> >> On Tue, Jul 18, 2023 at 8:43 PM Huacai Chen <chenhuacai@...nel.org> wrote:
> >> >> >
> >> >> > Hi, Luis,
> >> >> >
> >> >> > On Sat, Jul 1, 2023 at 7:25 AM Luis Chamberlain <mcgrof@...nel.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.
In another thread I had said that init and umh are special kernel
threads. But after your patient explanation, I admit init and umh are
user threads now. However I still don't think they are completely the
same as pthread_create()/sys_clone() so I say they are special user
threads. kernel_execve() makes init and umh user processes, but the
call to kernel_execve() is the internal logic of the created threads,
this logic has no direct relationship with 'user_mode_thread()'. And
it is also difficult for me to consider  'user_mode_thread()' as "a
special syscall", because syscall comes from userspace...

>
> > 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.
For me, 'thread' in the name has no problem. because 'task' is a
general concept, 'process' is a 'task' with independent address space,
and 'thread' is a 'task' with shared address space. I want to remove
'mode' because I like symmetry, and Andrew also thinks that 'mode' is
superfluous. Again, I admit init and umh are user threads, but they
are special so need a modifier. This modifier can be 'km' (stands for
'kernel mode') or 'kc' (stands for 'kernel created').


Huacai

>
> 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

Powered by blists - more mailing lists