Serge E. Hallyn [[email protected]] wrote:
| Quoting Sukadev Bhattiprolu ([email protected]):
| > +   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
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/containers

_______________________________________________
Devel mailing list
[email protected]
https://openvz.org/mailman/listinfo/devel

Reply via email to