kernel_thread bogosity

kernel_thread bogosity

[Pavel Machek]

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel_thread bogosity

[Andrea Arcangeli]

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

Re: kernel_thread bogosity

[Pavel Machek]

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel_thread bogosity

[Andrea Arcangeli]

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

Re: kernel_thread bogosity

[Pavel Machek]

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 pavel@ucw.cz. "In my country we have almost anarchy and I don't care."
Panos Katsaloulis describing me w.r.t. patents at discuss@linmodems.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: kernel_thread bogosity

[Andrea Arcangeli]

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