Hi, Eric, On Wed, Sep 13, 2023 at 1:30 AM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > > Huacai Chen <chenhuacai@xxxxxxxxxx> writes: > > > Hi, Eric, > > > > On Tue, Sep 12, 2023 at 9:59 AM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> wrote: > >> > >> Huacai Chen <chenhuacai@xxxxxxxxxx> writes: > >> > >> > Hi, all, > >> > > >> > Friendly ping again? > >> > > >> > > >> > Huacai > >> > > >> > On Sun, Jul 23, 2023 at 10:13 PM Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > >> >> > >> >> Hi, Eric, > >> >> > >> >> On Tue, Jul 18, 2023 at 8:43 PM Huacai Chen <chenhuacai@xxxxxxxxxx> wrote: > >> >> > > >> >> > Hi, Luis, > >> >> > > >> >> > On Sat, Jul 1, 2023 at 7:25 AM Luis Chamberlain <mcgrof@xxxxxxxxxx> 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
