Re: Do kernel threads need their own stack?

[Petr Vandrovec]

On 18 Jul 01 at 3:16, Brent Baccala wrote:

> The first thing I notice is that this function refers not only to the
> clone flags in ebx, but also to a "newsp" in ecx - and ecx went
> completely unmentioned in kernel_thread()!  A disassembly of
> 
> Anyway, I'm confused.  My analysis might be wrong, since I don't spend
> that much time in the Linux kernel, but bottom line - doesn't
> kernel_thread() need to allocate stack space for the child?  I mean,
> even if everything else is shared, doesn't the child at least need it's
> own stack?

ecx specifies where userspace stack lives, not kernel space one, and 
each process gets its own kernel stack automagically. As you must not
ever return to userspace from kernel_thread(), it is not a problem.
Because of exiting from kernel_thread() to userspace is not trivial
task, I do not think that is worth of effort.

If you are in doubts, you can trace code down to copy_thread. It copies
parent's registers as entered by int 0x80, and then uses ret_from_fork
for child's return path. So it returns to same place from where it
was invoked - in kernel_thread() case into kernel, with esp just being
on the top of kernel stack. And value passed for esp into clone() is lost
in that case, as it was stored in return stackframe esp field (oldesp
in entry.S) which was not used by processor because of it did not change 
its CPL to userspace (stack->cs & 3 was equal to %cs & 3, so stack pointer
was not fetched from stack).

Only problem I see is that we could give 8 more bytes to child by doing
add $8,%esp in child path in kernel_thread(), as currently we leave
these 8 bytes (oldesp, oldss) filled with garbage. But on other side,
if 8 bytes is everything what saves you from stack overflow, you are
in serious troubles anyway (in Linux, of course; 8 bytes is half of
your stack on i8048). And leaving it this way we ensure that child
has 16byte aligned stack on its enter, which can speed up code a bit
too.
                                        Best regards,
                                            Petr Vandrovec
                                            [e-mail]