[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121017160702.GY2616@ZenIV.linux.org.uk>
Date: Wed, 17 Oct 2012 17:07:03 +0100
From: Al Viro <viro@...IV.linux.org.uk>
To: Michal Simek <monstr@...str.eu>
Cc: Jonas Bonn <jonas@...thpole.se>, linux-kernel@...r.kernel.org,
linux-arch@...r.kernel.org,
Linus Torvalds <torvalds@...ux-foundation.org>,
Catalin Marinas <catalin.marinas@....com>,
Haavard Skinnemoen <hskinnemoen@...il.com>,
Mike Frysinger <vapier@...too.org>,
Jesper Nilsson <jesper.nilsson@...s.com>,
David Howells <dhowells@...hat.com>,
Tony Luck <tony.luck@...el.com>,
Benjamin Herrenschmidt <benh@...nel.crashing.org>,
Hirokazu Takata <takata@...ux-m32r.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>,
"James E.J. Bottomley" <jejb@...isc-linux.org>,
Richard Kuo <rkuo@...eaurora.org>,
Martin Schwidefsky <schwidefsky@...ibm.com>,
Lennox Wu <lennox.wu@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Paul Mundt <lethal@...ux-sh.org>,
Chris Zankel <chris@...kel.net>,
Chris Metcalf <cmetcalf@...era.com>,
Yoshinori Sato <ysato@...rs.sourceforge.jp>,
Guan Xuetao <gxt@...c.pku.edu.cn>
Subject: Re: new execve/kernel_thread design
On Wed, Oct 17, 2012 at 04:27:06PM +0200, Michal Simek wrote:
> In the patch above there is directly used current_pt_regs() function
> which works good for newly created threads
> when pt_regs are exactly in current_pt_regs() position but not for
> pt_regs which are saved on the stack
> which is the init task case.
init_task does *not* do kernel_execve(). It's PID 0, not PID 1.
init is spawned by it.
> My question is how should /init be called? Because I need to save
> pt_regs to current_pt_regs() position where
> generic kernel_execve expects it.
What happens during boot is this:
* init_task (not to be confused with init) is used as current during
infrastructure initializations. Once everything needed for scheduler and
for working fork is set, we spawn two threads - future init and future
kthreadd. The last thing we do with init_task is telling init that kthreadd
has been spawned. After that init_task turns itself into an idle thread.
* future init waits for kthreadd to be spawned (it would be more
natural to fork them in opposite order, but we want init to have PID 1 -
too much stuff in userland depends on that). Then it does the rest of
initialization, including setting up initramfs contents. And does
kernel_execve() on /init. Note that this is a task that had been created
by kernel_thread() and is currently in function called from
ret_from_kernel_thread(). Its kernel stack has been set up by copy_thread().
That's where pt_regs need to be set up; note that they'll be passed to
start_thread() before you return to userland. If there are any magic bits
in pt_regs needed by return-from-syscall code, set them in kthread case of
copy_thread().
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists