kernel_thread bogosity

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]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

"=&a" (retval)

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.

Not necessary because a kernel thread never exit from kernel.

Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi!

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]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

... 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

Hi!

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]
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/