Messages in this thread | | | From | Linus Torvalds <> | Date | Sat, 25 Jun 2022 16:43:39 -0700 | Subject | Re: re. Spurious wakeup on a newly created kthread |
| |
On Sat, Jun 25, 2022 at 4:28 PM Eric W. Biederman <ebiederm@xmission.com> wrote: > > I presume you mean kthreadd games?
Yeah, sorry.
> So with the introduction of kthreadd the kernel threads were moved > out of the userspace process tree, and userspace stopped being able to > influence the kernel threads.
Ahh. So essentially it's indeed just basically the parenting issue.
> I want to say that all that is required is that copy_process copies > from kthreadd. Unfortunately that means that it needs to be kthreadd > doing the work, as copy_process does always copies from current. It > would take quite a bit of work to untangle that mess.
Hmm. Yeah, it would probably be painful to replace 'current' with something else, due to locking etc. Using "current" has some fundamental advantages wrt using another thread pointer that may or may not be active at the same time.
That said, there *is* another thread that has very similar "we don't need locking, because it's always around and it doesn't change": init_task.
I wonder if we could basically get rid of every use of 'current' in kernel/fork.c with just a task pointer that is passed in, and then for kernel threads pass in 'init_task'.
I'd hate to duplicate copy_process() entirely, when we probably could just consider it just a parenting issue, and say that you can have either 'current' or 'init_task' as the parent. And that 'init_task' would basically be the 'clean slate for kthreads'.
Christian, comments?
Linus
| |