Sukadev Bhattiprolu wrote:
> | Call clone_with_pids as follows:
> |
> | pid_t pids[] = { 0, 77, 99 };
> | struct target_pid_set pid_set;
> |
> | pid_set.num_pids = sizeof(pids) / sizeof(int);
> | pid_set.target_pids = &pids;
> |
> | syscall(__NR_clone_with_pids, flags, stack, NULL, NULL, NULL, &pid_set);
>
>
> Now that we need to do a copy_from_user() anyway, is it worth collapsing
> one or more parameters into a structure ?
Definitely so.
>
> struct clone_with_pid_args {
> u64 flags;
> void *stack;
> void *tls;
> struct target_pid_set *pid_set;
> };
>
> struct clone_tid_info {
> int *parent_tidptr;
> int *child_tidptr;
> }
>
> struct clone_with_pid_args cwp_args;
> struct clone_tid_info ctid_inf;
>
> ...
>
> syscall(__NR_clone_with_pids, &cwp_args, &ctid_info);
>
> One advantage would be that it would make room for 64 bit clone flags, so we
> won't need a new flavor of clone_with_pids() when clone_flags is extended.
Because clone_with_pids() is a super-set of clone(), it is possible
that it (itself) becomes the successor that allows 64-bit clone flags.
(instead of, say, adding a clone64, clone2, clone_next_generation etc).
To allow this, we need to be careful to not copy_from_user for the
when fast-path is needed for common thread/task creation, if possible.
Oren.
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
