| Message ID | 20230615121016.3731983-1-chenhuacai@loongson.cn (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | kthread: Rename user_mode_thread() to kmuser_thread() | expand |
Friendly ping? Huacai On Thu, Jun 15, 2023 at 8:10 PM Huacai Chen <chenhuacai@loongson.cn> 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 <chenhuacai@loongson.cn> > --- > 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 <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. Huacai > > Luis
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. Huacai > > Huacai > > > > Luis
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. > > Huacai > > > > Huacai > > > > > > Luis
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. Eric
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). 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 <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
Hi, Eric, On Wed, Sep 13, 2023 at 1:30 AM Eric W. Biederman <ebiederm@xmission.com> wrote: > > 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. 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
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;
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 <chenhuacai@loongson.cn> --- 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(-)