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]
Message-ID: <CAHk-=whX_=BNZ4kVEAu2NV3CMnhwsuYTyE65FQXUMx8VPNOAOA@mail.gmail.com>
Date:   Sat, 25 Jun 2022 16:48:38 -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:43 PM Linus Torvalds
<torvalds@...ux-foundation.org> wrote:
>
> 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'.

That might even help code generation. Instead of doing the 'look up
current' all the time, just having the parent task as an argument
might actually simplify things.

We historically used to do those kinds of things exactly because it
helps generate better code (particularly with inline functions, and
things like 'exit' that calls many different things), but have mostly
avoided it because 'current' may generate some small asm snippet all
the time, but it clarifies the "it can't be a random thread" and
locking issues.

But if it's always 'current or init_task', we don't have many locking issues.

Of course, there might be some reason not to want to use init_task
because it is _so_ special, and so parenting to something silly like
kthreadd ends up being simpler. But..

Anyway, the whole "don't wake up thread until it's all done" is a
separate and independent issue from the "odd use of kthreadd" issue.

          Linus

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ