[<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