linux-kernel - Re: re. Spurious wakeup on a newly created kthread

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Sat, 25 Jun 2022 11:43:15 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>,
        Christian Brauner <brauner@...nel.org>
Cc:     Tejun Heo <tj@...nel.org>, Petr Mladek <pmladek@...e.com>,
        Lai Jiangshan <jiangshanlai@...il.com>,
        Michal Hocko <mhocko@...e.com>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Oleg Nesterov <oleg@...hat.com>
Subject: Re: re. Spurious wakeup on a newly created kthread

On Sat, Jun 25, 2022 at 11:25 AM Linus Torvalds
<torvalds@...ux-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