Re: re. Spurious wakeup on a newly created kthread

[Linus Torvalds <torvalds@linux-foundation.org>]

On Sat, Jun 25, 2022 at 11:25 AM Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> And that's not at all what the kthread code wants. It wants to set
> affinity masks, it wants to create a name for the thread, it wants to
> do all those other things.
>
> That code really wants to just do copy_process().

Honestly, I think kernel/kthread.c should be almost rewritten from scratch.

I do not understand why it does all those odd keventd games at all,
and why kthread_create_info exists in the first place.

Why does kthread_create() not just create the thread directly itself,
and instead does that odd queue it onto a work function?

Some of that goes back to before the git history, and very little of
it seems to make any sense. It's as if the code is meant to be able to
run from interrupt context, but that can't be it: it's literally doing
a GFP_KERNEL kmalloc, it's doing spin-locks without irq safety etc.

So why is it calling kthreadd_task() to create the thread? Purely for
some crazy odd "make that the parent" reason?

I dunno.  The code is odd, unexplained, looks buggy, and most fo the
reasons are probably entirely historical.

I'm adding Christian to this thread too, since I get the feeling that
it really should be more tightly integrated with copy_process(), and
that Christian might have comments.

Christian, see some context in the thread here:

  https://lore.kernel.org/all/CAHk-=wiC7rj1o7vTnYUPfD7YxAu09MZiZbahHqvLm9+Cgg1dFw@mail.gmail.com/

for some of this.

               Linus