Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp4008909ybl; Mon, 12 Aug 2019 09:53:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqzhy0uooug+/4Q0KAR6y7YtIo/PxEkohCnlapwR44DmNXpnm4zsTIoYlfMIrLpjvRc0W4ci X-Received: by 2002:a63:dd17:: with SMTP id t23mr30279683pgg.295.1565628786678; Mon, 12 Aug 2019 09:53:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1565628786; cv=none; d=google.com; s=arc-20160816; b=YU3OVHkLgzmR/Do6a4YDX7cjDgDVWgMvXUkL4qvqC7s2ip+lvD4RUztx+61l9cx81C FfBmbncCr0/Ana69AcgYMvJPWd2XnJjDStW4nIrjryRPB2WvlQ389rLdGeCd9ls4M2Hk jBPKV5ktj+ooSCCxAFAXdtQPMj4PmgKbvwQbM1aZ8FN5DE1G9h8vSCVvEwWwNLPpMZO0 eaQlP1EJHvT8yLOQ9HvhrF6TtSeB30PMbaeeh/5KZtMmJRbJWyuqz0BgfxxxK5pQZQS6 JLIjuNo3RZU5926fZEntw5wV+KKkOGcRnKqWe0G6CPWFVzaVt2qnnq/fkqpSJIObcXrz Gvng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=uSsXfz1pQlHPOZWBA/oNSy9tYKYw+Bo86U7HTLHtn20=; b=P3hMnOlJvLIOGO5fBPnEGIETMAbY/RWmrIRSOcTNYF/WDQ1kOdexbOoCWs+dmS0AtH TPdFjBBd+ETONTyiI8pECqCrkEGJ8VSmksyedLr5VHQpEpkaxNmBn5C92oKID9N8CsNF 5bF3t2hh5r4PQXc/UGFRDT33PgwY/vrK3ObCje5WDE65NT8zss6iGFC8hieNqqkSQiJe w4yFbMlimDm3h7funG4M/go/yyw1dB/yklmfRb53oRO6AgCqm8k/v9gJ3ysELruzM138 lWDkLUE5HnOl35zIU6pRmbivmicDfUFknvwyfa5ex7Yb5tLap8hDlRVD4KDrkByYLEpc X7vw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r8si4504344pfh.185.2019.08.12.09.52.51; Mon, 12 Aug 2019 09:53:06 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726674AbfHLQvs (ORCPT + 99 others); Mon, 12 Aug 2019 12:51:48 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:52108 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725843AbfHLQvs (ORCPT ); Mon, 12 Aug 2019 12:51:48 -0400 Received: from [213.220.153.21] (helo=wittgenstein) by youngberry.canonical.com with esmtpsa (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.76) (envelope-from ) id 1hxDXf-0003Da-H4; Mon, 12 Aug 2019 16:51:31 +0000 Date: Mon, 12 Aug 2019 18:51:30 +0200 From: Christian Brauner To: Oleg Nesterov Cc: Adrian Reber , Eric Biederman , Pavel Emelianov , Jann Horn , Dmitry Safonov <0x7f454c46@gmail.com>, linux-kernel@vger.kernel.org, Andrei Vagin , Mike Rapoport , Radostin Stoyanov Subject: Re: [PATCH v5 1/2] fork: extend clone3() to support CLONE_SET_TID Message-ID: <20190812165130.d3b5smm45dpxk6m4@wittgenstein> References: <20190811203327.5385-1-areber@redhat.com> <20190812163710.GC31560@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20190812163710.GC31560@redhat.com> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Aug 12, 2019 at 06:37:10PM +0200, Oleg Nesterov wrote: > On 08/11, Adrian Reber wrote: > > > > include/linux/pid.h | 2 +- > > include/linux/sched/task.h | 1 + > > include/uapi/linux/sched.h | 1 + > > kernel/fork.c | 22 ++++++++++++++++++++-- > > kernel/pid.c | 36 +++++++++++++++++++++++++++++------- > > 5 files changed, 52 insertions(+), 10 deletions(-) > > Looks good to me... > > A couple of nits below, but I won't insist, feel free to ignore. > > > +/* > > + * Different sizes of struct clone_args > > + */ > > +#define CLONE3_ARGS_SIZE_V0 64 > > I don't really understand why do we want the "size < CLONE3_ARGS_SIZE_V0" > check in copy_clone_args_from_user(), but I won't argue. To make sure a user can't give us a garbage sized struct that is smaller than the initial version of the struct. Hm, maybe you did make a suggestion how to detect this case that I missed in one of the previous reviews or why it's not needed?