Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp1457766ybi; Fri, 2 Aug 2019 16:22:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqzgkJIpGp8yZHomgtnnN/r/c4GeUp6KTqHIAcUF2bW5DcDMNX4MfzbM5b/H3VH/FgoJCSyj X-Received: by 2002:a63:67c6:: with SMTP id b189mr35417377pgc.163.1564788157147; Fri, 02 Aug 2019 16:22:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1564788157; cv=none; d=google.com; s=arc-20160816; b=GmC4xk10hxy7ztl90ILxJD8SpyhR/Rm25NTyGl8+zWluwdl4ldx41yy8jJNudyPgk6 yoNNPLxO7p2ezr2GhrODOIzMfuYHywyZs/thBBqNRgGXttNyA0DjHsRQb++BRChZ8N50 /3MV5vCBle7PaJjSK0XIudvhsbtGGNk//zvWxSHj+57ba8rlqjlf9DKoT+bOdKpLiJ8Y YU1qbReD8oj7/oqvOjmGhvVdS5dutGmIfFjL4WhrHH1FllrhyufiJ/OHNM9ZHIZevB+m ehqQ0uOMBaeZTSjhVF1i80E2rdU2FTC8VsXzMgoFPICPMk3qfj8pWNd/FVggrqoQTE8n G11g== 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=UjijmnJw1nTF3sm7pULrXJpvVIW2ZZGdvx0DcAIagCo=; b=PTD93iAnH9C3geN7wmMycEr1hNVA1goBkC5G0SdbVLPRq8y7DzzUyK/7GtFsCBprr1 xEd50wHSa2DuPHQMye1GVl5eRzL6AtuRUKe5ZEDXyuL6psp6lxp5TiK0PAzLR3hV7CHo 5/jVfsedaDSzS1GmYEd+/epcgxr0l/mR8SMuGMAaysA3mMoRZW+ZkYTMBT01mExoPsdH oB45txaJAdxie9G2xGkXlIAKEhL1Z/w7wfp0A5EEUCkven2TjySA9noIaZPr1UPIYall Vi/ogf+H8ZosvSo2i4FL/OL0kZBqdyWKRbjeJDr2KVUZYq2jRYlaxSCax9a3/5L5KzKo vjBg== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id l70si38837269pge.446.2019.08.02.16.22.21; Fri, 02 Aug 2019 16:22:37 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389733AbfHBMrm (ORCPT + 99 others); Fri, 2 Aug 2019 08:47:42 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53230 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730003AbfHBMrm (ORCPT ); Fri, 2 Aug 2019 08:47:42 -0400 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BEFE1C027339; Fri, 2 Aug 2019 12:47:41 +0000 (UTC) Received: from dhcp-27-174.brq.redhat.com (unknown [10.43.17.136]) by smtp.corp.redhat.com (Postfix) with SMTP id 69753608C2; Fri, 2 Aug 2019 12:47:39 +0000 (UTC) Received: by dhcp-27-174.brq.redhat.com (nbSMTP-1.00) for uid 1000 oleg@redhat.com; Fri, 2 Aug 2019 14:47:41 +0200 (CEST) Date: Fri, 2 Aug 2019 14:47:38 +0200 From: Oleg Nesterov To: Adrian Reber Cc: Christian Brauner , 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 v2 1/2] fork: extend clone3() to support CLONE_SET_TID Message-ID: <20190802124738.GC20111@redhat.com> References: <20190731161223.2928-1-areber@redhat.com> <20190731174135.GA30225@redhat.com> <20190802072511.GD18263@dcbz.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190802072511.GD18263@dcbz.redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Fri, 02 Aug 2019 12:47:42 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 08/02, Adrian Reber wrote: > > On Wed, Jul 31, 2019 at 07:41:36PM +0200, Oleg Nesterov wrote: > > But the main question is how it can really help if ns->level > 0, unlikely > > CRIU will ever need to clone the process with the same pid_nr == set_tid > > in the ns->parent chain. > > Not sure I understand what you mean. For CRIU only the PID in the PID > namespace is relevant. If it runs "inside" this namespace. But in this case alloc_pid() should use nr == set_tid only once in the main loop, when i == ns->level. It doesn't need to have the same pid_nr in the parent pid namespace. And in fact we should not allow criu (or anything else) to control the child's pid_nr in the parent(s) namespace. Right? > > So may be kernel_clone_args->set_tid should be pid_t __user *set_tid_array? > > Or I missed something ? > > Not sure why and how an array would be needed. Could you give me some > more details why you think this is needed. IIURC, criu can restore the process tree along with nested pid namespaces. how can this patch help in this case? But again, perhaps I missed something. I forgot everything about criu. Oleg.