Hi!
You see? Kernel_thread does not check is sys_clone() worked! Aha,
caller is responsible for that, but init/main.c does not seem too
carefull. Maybe kernel_thread should at least print a warning?
Plus, can someone explain me why it does not need to setup %%ecx with
either zero or address of stack?
Pavel
int kernel_thread(int (*fn)(void *), void * arg, unsigned long flags)
{
long retval, d0;
__asm__ __volatile__(
"movl %%esp,%%esi\n\t"
"int $0x80\n\t" /* Linux/i386 system call */
"cmpl %%esp,%%esi\n\t" /* child or parent? */
"je 1f\n\t" /* parent - jump */
/* Load the argument into eax, and push it. That way,
it does
* not matter whether the called function is compiled
with
* -mregparm or not. */
"movl %4,%%eax\n\t"
"pushl %%eax\n\t"
"call *%5\n\t" /* call fn */
"movl %3,%0\n\t" /* exit */
"int $0x80\n"
"1:\t"
:"=&a" (retval), "=&S" (d0)
:"0" (__NR_clone), "i" (__NR_exit),
"r" (arg), "r" (fn),
"b" (flags | CLONE_VM)
: "memory");
return retval;
}
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
On Thu, Nov 23, 2000 at 11:23:33PM +0100, Pavel Machek wrote:
> Hi!
>
> You see? Kernel_thread does not check is sys_clone() worked! Aha,
"=&a" (retval)
> caller is responsible for that, but init/main.c does not seem too
> carefull. Maybe kernel_thread should at least print a warning?
If clone fails during start_kernel that's the last of your problems so nobody
cared. If you want to add a check on the retval go ahead, that's right indeed.
> Plus, can someone explain me why it does not need to setup %%ecx with
> either zero or address of stack?
Not necessary because a kernel thread never exit from kernel.
Andrea
Hi!
> > Plus, can someone explain me why it does not need to setup %%ecx with
> > either zero or address of stack?
>
> Not necessary because a kernel thread never exit from kernel.
How can that work? restore_args ends with iret, anyway, and iret does
reload esp afaics...
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
On Fri, Nov 24, 2000 at 08:52:47PM +0100, Pavel Machek wrote:
> How can that work? restore_args ends with iret, anyway, and iret does
> reload esp afaics...
... only if there's an IPL change during the iret. Page 3-321 of 24319102.pdf
from Intel:
[..] If the return is to another privilege level, the IRET instruction
also pops the stack pointer and SS from the stack, before resuming
program execution. [..]
Andrea
Hi!
> > How can that work? restore_args ends with iret, anyway, and iret does
> > reload esp afaics...
>
> ... only if there's an IPL change during the iret. Page 3-321 of 24319102.pdf
> from Intel:
>
> [..] If the return is to another privilege level, the IRET instruction
> also pops the stack pointer and SS from the stack, before resuming
> program execution. [..]
Is this different on x86-64 in long mode?
Pavel
--
I'm [email protected]. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at [email protected]
On Sun, Nov 26, 2000 at 11:29:32PM +0100, Pavel Machek wrote:
> Is this different on x86-64 in long mode?
Yes, in 64bit mode ss:rsp is restore unconditionally. In compatibility and
legacy modes it's restored only if the CPL changes.
kernel never runs in compatibility mode (and userspace never runs iret) so in
kernel_thread we know x86-64 always restores ss:rsp from the stack.
You should find this as a familiar behaviour as you just tried to pass a stack
via kernel_thread in your latest patch against cvs :).
Andrea