Commit 343f4c49f2438d8 ("kthread: Don't allocate kthread_struct for init
and umh") introduces a new function user_mode_thread() for init and umh.
init and umh are different from typical kernel threads since the don't
need a "kthread" struct and they will finally become user processes by
calling kernel_execve(), but on the other hand, they are also different
from typical user mode threads (they have no "mm" structs at creation
time, which is traditionally used to distinguish a user thread and a
kernel thread).
In a former patch I treat init and umh as "special kernel threads" and
unify kernel_thread() and user_mode_thread() to kernel_thread() again.
However, the patch has been nacked because init and umh are essentially
"special user threads".
Nevertheless, I still agree with Andrews' comment "But the naming isn't
very good anyway. They should have been usermode_thread/kernel_thread or
user_thread/kernel_thread.".
Since Eric describes init and umh as "user threads run in kernel mode",
in this patch I rename user_mode_thread() as kmuser_thread(), which is
a little better than just user_thread().
Signed-off-by: Huacai Chen <[email protected]>
---
include/linux/sched/task.h | 2 +-
init/main.c | 2 +-
kernel/fork.c | 4 ++--
kernel/umh.c | 4 ++--
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
index e0f5ac90a228..c774d604b0a3 100644
--- a/include/linux/sched/task.h
+++ b/include/linux/sched/task.h
@@ -98,7 +98,7 @@ struct task_struct *create_io_thread(int (*fn)(void *), void *arg, int node);
struct task_struct *fork_idle(int);
extern pid_t kernel_thread(int (*fn)(void *), void *arg, const char *name,
unsigned long flags);
-extern pid_t user_mode_thread(int (*fn)(void *), void *arg, unsigned long flags);
+extern pid_t kmuser_thread(int (*fn)(void *), void *arg, unsigned long flags);
extern long kernel_wait4(pid_t, int __user *, int, struct rusage *);
int kernel_wait(pid_t pid, int *stat);
diff --git a/init/main.c b/init/main.c
index af50044deed5..362ba90d6f73 100644
--- a/init/main.c
+++ b/init/main.c
@@ -697,7 +697,7 @@ noinline void __ref __noreturn rest_init(void)
* the init task will end up wanting to create kthreads, which, if
* we schedule it before we create kthreadd, will OOPS.
*/
- pid = user_mode_thread(kernel_init, NULL, CLONE_FS);
+ pid = kmuser_thread(kernel_init, NULL, CLONE_FS);
/*
* Pin init on the boot CPU. Task migration is not properly working
* until sched_init_smp() has been run. It will set the allowed
diff --git a/kernel/fork.c b/kernel/fork.c
index 41c964104b58..57d5c8c1766e 100644
--- a/kernel/fork.c
+++ b/kernel/fork.c
@@ -2978,9 +2978,9 @@ pid_t kernel_thread(int (*fn)(void *), void *arg, const char *name,
}
/*
- * Create a user mode thread.
+ * Create a kernel mode user thread.
*/
-pid_t user_mode_thread(int (*fn)(void *), void *arg, unsigned long flags)
+pid_t kmuser_thread(int (*fn)(void *), void *arg, unsigned long flags)
{
struct kernel_clone_args args = {
.flags = ((lower_32_bits(flags) | CLONE_VM |
diff --git a/kernel/umh.c b/kernel/umh.c
index 60aa9e764a38..28c0cf0da7be 100644
--- a/kernel/umh.c
+++ b/kernel/umh.c
@@ -130,7 +130,7 @@ static void call_usermodehelper_exec_sync(struct subprocess_info *sub_info)
/* If SIGCLD is ignored do_wait won't populate the status. */
kernel_sigaction(SIGCHLD, SIG_DFL);
- pid = user_mode_thread(call_usermodehelper_exec_async, sub_info, SIGCHLD);
+ pid = kmuser_thread(call_usermodehelper_exec_async, sub_info, SIGCHLD);
if (pid < 0)
sub_info->retval = pid;
else
@@ -169,7 +169,7 @@ static void call_usermodehelper_exec_work(struct work_struct *work)
* want to pollute current->children, and we need a parent
* that always ignores SIGCHLD to ensure auto-reaping.
*/
- pid = user_mode_thread(call_usermodehelper_exec_async, sub_info,
+ pid = kmuser_thread(call_usermodehelper_exec_async, sub_info,
CLONE_PARENT | SIGCHLD);
if (pid < 0) {
sub_info->retval = pid;
--
2.39.3
Friendly ping?
Huacai
On Thu, Jun 15, 2023 at 8:10 PM Huacai Chen <[email protected]> wrote:
>
> Commit 343f4c49f2438d8 ("kthread: Don't allocate kthread_struct for init
> and umh") introduces a new function user_mode_thread() for init and umh.
>
> init and umh are different from typical kernel threads since the don't
> need a "kthread" struct and they will finally become user processes by
> calling kernel_execve(), but on the other hand, they are also different
> from typical user mode threads (they have no "mm" structs at creation
> time, which is traditionally used to distinguish a user thread and a
> kernel thread).
>
> In a former patch I treat init and umh as "special kernel threads" and
> unify kernel_thread() and user_mode_thread() to kernel_thread() again.
> However, the patch has been nacked because init and umh are essentially
> "special user threads".
>
> Nevertheless, I still agree with Andrews' comment "But the naming isn't
> very good anyway. They should have been usermode_thread/kernel_thread or
> user_thread/kernel_thread.".
>
> Since Eric describes init and umh as "user threads run in kernel mode",
> in this patch I rename user_mode_thread() as kmuser_thread(), which is
> a little better than just user_thread().
>
> Signed-off-by: Huacai Chen <[email protected]>
> ---
> include/linux/sched/task.h | 2 +-
> init/main.c | 2 +-
> kernel/fork.c | 4 ++--
> kernel/umh.c | 4 ++--
> 4 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/include/linux/sched/task.h b/include/linux/sched/task.h
> index e0f5ac90a228..c774d604b0a3 100644
> --- a/include/linux/sched/task.h
> +++ b/include/linux/sched/task.h
> @@ -98,7 +98,7 @@ struct task_struct *create_io_thread(int (*fn)(void *), void *arg, int node);
> struct task_struct *fork_idle(int);
> extern pid_t kernel_thread(int (*fn)(void *), void *arg, const char *name,
> unsigned long flags);
> -extern pid_t user_mode_thread(int (*fn)(void *), void *arg, unsigned long flags);
> +extern pid_t kmuser_thread(int (*fn)(void *), void *arg, unsigned long flags);
> extern long kernel_wait4(pid_t, int __user *, int, struct rusage *);
> int kernel_wait(pid_t pid, int *stat);
>
> diff --git a/init/main.c b/init/main.c
> index af50044deed5..362ba90d6f73 100644
> --- a/init/main.c
> +++ b/init/main.c
> @@ -697,7 +697,7 @@ noinline void __ref __noreturn rest_init(void)
> * the init task will end up wanting to create kthreads, which, if
> * we schedule it before we create kthreadd, will OOPS.
> */
> - pid = user_mode_thread(kernel_init, NULL, CLONE_FS);
> + pid = kmuser_thread(kernel_init, NULL, CLONE_FS);
> /*
> * Pin init on the boot CPU. Task migration is not properly working
> * until sched_init_smp() has been run. It will set the allowed
> diff --git a/kernel/fork.c b/kernel/fork.c
> index 41c964104b58..57d5c8c1766e 100644
> --- a/kernel/fork.c
> +++ b/kernel/fork.c
> @@ -2978,9 +2978,9 @@ pid_t kernel_thread(int (*fn)(void *), void *arg, const char *name,
> }
>
> /*
> - * Create a user mode thread.
> + * Create a kernel mode user thread.
> */
> -pid_t user_mode_thread(int (*fn)(void *), void *arg, unsigned long flags)
> +pid_t kmuser_thread(int (*fn)(void *), void *arg, unsigned long flags)
> {
> struct kernel_clone_args args = {
> .flags = ((lower_32_bits(flags) | CLONE_VM |
> diff --git a/kernel/umh.c b/kernel/umh.c
> index 60aa9e764a38..28c0cf0da7be 100644
> --- a/kernel/umh.c
> +++ b/kernel/umh.c
> @@ -130,7 +130,7 @@ static void call_usermodehelper_exec_sync(struct subprocess_info *sub_info)
>
> /* If SIGCLD is ignored do_wait won't populate the status. */
> kernel_sigaction(SIGCHLD, SIG_DFL);
> - pid = user_mode_thread(call_usermodehelper_exec_async, sub_info, SIGCHLD);
> + pid = kmuser_thread(call_usermodehelper_exec_async, sub_info, SIGCHLD);
> if (pid < 0)
> sub_info->retval = pid;
> else
> @@ -169,7 +169,7 @@ static void call_usermodehelper_exec_work(struct work_struct *work)
> * want to pollute current->children, and we need a parent
> * that always ignores SIGCHLD to ensure auto-reaping.
> */
> - pid = user_mode_thread(call_usermodehelper_exec_async, sub_info,
> + pid = kmuser_thread(call_usermodehelper_exec_async, sub_info,
> CLONE_PARENT | SIGCHLD);
> if (pid < 0) {
> sub_info->retval = pid;
> --
> 2.39.3
>
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.
Luis
Hi, Luis,
On Sat, Jul 1, 2023 at 7:25 AM Luis Chamberlain <[email protected]> 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.
Huacai
>
> Luis
Hi, Eric,
On Tue, Jul 18, 2023 at 8:43 PM Huacai Chen <[email protected]> wrote:
>
> Hi, Luis,
>
> On Sat, Jul 1, 2023 at 7:25 AM Luis Chamberlain <[email protected]> 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.
Huacai
>
> Huacai
> >
> > Luis
Huacai Chen <[email protected]> writes:
> Hi, all,
>
> Friendly ping again?
>
>
> Huacai
>
> On Sun, Jul 23, 2023 at 10:13 PM Huacai Chen <[email protected]> wrote:
>>
>> Hi, Eric,
>>
>> On Tue, Jul 18, 2023 at 8:43 PM Huacai Chen <[email protected]> wrote:
>> >
>> > Hi, Luis,
>> >
>> > On Sat, Jul 1, 2023 at 7:25 AM Luis Chamberlain <[email protected]> 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
Hi, Eric,
On Tue, Sep 12, 2023 at 9:59 AM Eric W. Biederman <[email protected]> wrote:
>
> Huacai Chen <[email protected]> writes:
>
> > Hi, all,
> >
> > Friendly ping again?
> >
> >
> > Huacai
> >
> > On Sun, Jul 23, 2023 at 10:13 PM Huacai Chen <[email protected]> wrote:
> >>
> >> Hi, Eric,
> >>
> >> On Tue, Jul 18, 2023 at 8:43 PM Huacai Chen <[email protected]> wrote:
> >> >
> >> > Hi, Luis,
> >> >
> >> > On Sat, Jul 1, 2023 at 7:25 AM Luis Chamberlain <[email protected]> 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
Huacai Chen <[email protected]> writes:
> Hi, Eric,
>
> On Tue, Sep 12, 2023 at 9:59 AM Eric W. Biederman <[email protected]> wrote:
>>
>> Huacai Chen <[email protected]> writes:
>>
>> > Hi, all,
>> >
>> > Friendly ping again?
>> >
>> >
>> > Huacai
>> >
>> > On Sun, Jul 23, 2023 at 10:13 PM Huacai Chen <[email protected]> wrote:
>> >>
>> >> Hi, Eric,
>> >>
>> >> On Tue, Jul 18, 2023 at 8:43 PM Huacai Chen <[email protected]> wrote:
>> >> >
>> >> > Hi, Luis,
>> >> >
>> >> > On Sat, Jul 1, 2023 at 7:25 AM Luis Chamberlain <[email protected]> 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
Hi, Eric,
On Wed, Sep 13, 2023 at 1:30 AM Eric W. Biederman <[email protected]> wrote:
>
> Huacai Chen <[email protected]> writes:
>
> > Hi, Eric,
> >
> > On Tue, Sep 12, 2023 at 9:59 AM Eric W. Biederman <[email protected]> wrote:
> >>
> >> Huacai Chen <[email protected]> writes:
> >>
> >> > Hi, all,
> >> >
> >> > Friendly ping again?
> >> >
> >> >
> >> > Huacai
> >> >
> >> > On Sun, Jul 23, 2023 at 10:13 PM Huacai Chen <[email protected]> wrote:
> >> >>
> >> >> Hi, Eric,
> >> >>
> >> >> On Tue, Jul 18, 2023 at 8:43 PM Huacai Chen <[email protected]> wrote:
> >> >> >
> >> >> > Hi, Luis,
> >> >> >
> >> >> > On Sat, Jul 1, 2023 at 7:25 AM Luis Chamberlain <[email protected]> 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