linux-kernel - Re: [PATCH] kthread: Rename user_mode_thread() to kmuser

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAAhV-H7D85NTS+8VP6ELiiMVrFkarhjBFbHERLbA9azaK9=XcQ@mail.gmail.com>
Date:   Tue, 12 Sep 2023 23:31:12 +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 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).
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’. 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’.

Huacai

>
> Eric