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 16:43:39 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     "Eric W. Biederman" <ebiederm@...ssion.com>
Cc:     Christian Brauner <brauner@...nel.org>, 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 4:28 PM Eric W. Biederman <ebiederm@...ssion.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