Re: re. Spurious wakeup on a newly created kthread

[Linus Torvalds]

On Sat, Jun 25, 2022 at 4:28 PM Eric W. Biederman <ebiederm@xxxxxxxxxxxx> 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