[Devel] Re: [v11][PATCH 8/9] Define clone_with_pids() syscall

Sukadev Bhattiprolu sukadev at linux.vnet.ibm.com
Sat Nov 7 12:18:10 PST 2009


Serge E. Hallyn [serue at us.ibm.com] wrote:
| Quoting Sukadev Bhattiprolu (sukadev at us.ibm.com):
| > +	stack_size = (unsigned long)kca.child_stack_size;
| > +	child_stack = (unsigned long)kca.child_stack_base + stack_size;
| > +
| > +	if (!child_stack)
| > +		child_stack = regs->sp;
| 
| I'm hooking up the s390 version right now.  Do you think you should
| make this
| 
| 	if (!kca.child_stack_base)
| 		child_stack = regs->sp;
| 
| ?
| 
| I suppose that in general if I pass in a NULL kca.child_stack_base
| I'll also pass in a 0 stacksize, but as a user I'd expect that if
| I pass in NULL, the size gets ignored.  Instead, if I pass in NULL
| plus a size, then the kernel will take (void *)size as the stacktop.

Good point. Like copy_thread() on IA64, how about ignoring 'stack_size'
if base is NULL ?

        child_stack = 0UL;
        if (kca.child_stack_base)
                child_stack = (unsigned long)kca.child_stack_base + stack_size;

        if (!child_stack)
                child_stack = regs->sp;

The other question is whether we should force all architectures to pass in
the stack *base* ? clone(2) man page says:

	Stacks grow  downwards  on  all  processors  that  run  Linux (except
	the  HP  PA  processors), so child_stack usually points to the topmost
	address of the memory space set up for the child stack.

To be compatibile with clone() on most architectures, should we rename
'clone_args.child_stack_base' to 'clone_args.child_stack' and let
architectures use this field like they currently use the 'child_stack'
parameter to clone(2) ?

So x86 would pass in address of top-of-stack while HP-PA can pass in address
of base-of-stack.

Arnd, Roland, Peter please let me know if you have any inputs on this.

Sukadev
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers




More information about the Devel mailing list