Re: [PATCH v3 1/2] fork: extend clone3() to support CLONE_SET_TID

From: Dmitry Safonov
Date: Wed Aug 07 2019 - 12:33:34 EST


On 8/7/19 5:21 PM, Oleg Nesterov wrote:
> On 08/07, Dmitry Safonov wrote:
[..]
>> What if the size is lesser than offsetof(struct clone_args, stack_size)?
>> Probably, there should be still a check that it's not lesser than what's
>> the required minimum..
>
> Not sure I understand... I mean, this doesn't differ from the case when
> size == sizeof(clone_args) but uargs->stack == NULL ?

I might be mistaken and I confess that I don't fully understand the
code, but wouldn't it mystically fail in copy_thread_tls() with -ENOMEM
instead of -EINVAL?
Maybe not a huge difference, but..

>> Also note, that (kargs) and (args) are a bit different beasts in this
>> context..
>> kargs lies on the stack and might want to be with zero-initializer
>> : struct kernel_clone_args kargs = {};
>
> I don't think so. Lets consider this patch which adds the new set_tid
> into clone_args and kernel_clone_args. copy_clone_args_from_user() does
>
> *kargs = (struct kernel_clone_args){
> .flags = args.flags,
> .pidfd = u64_to_user_ptr(args.pidfd),
> .child_tid = u64_to_user_ptr(args.child_tid),
> .parent_tid = u64_to_user_ptr(args.parent_tid),
> .exit_signal = args.exit_signal,
> .stack = args.stack,
> .stack_size = args.stack_size,
> .tls = args.tls,
> };
>
> so this patch should simply add
>
> .set_tid = args.set_tid;
>
> at the end. No?
Agree, this may be better.

--
Dmitry