Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp5128155yba; Tue, 30 Apr 2019 09:33:37 -0700 (PDT) X-Google-Smtp-Source: APXvYqwtmnoLgt6LsYPDz72/XU1l8x2YfJYEffR708ySDjJDOwaWEr5ZzV9VkDsPxGYzuxK4KvZI X-Received: by 2002:a62:5915:: with SMTP id n21mr16230372pfb.180.1556642017864; Tue, 30 Apr 2019 09:33:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1556642017; cv=none; d=google.com; s=arc-20160816; b=pVE14bSo8PIZSpn7DyOnCrXSk2K0fT1NAjAdrj4aksIg7hER0TdRplMlZdPo01qAc+ rageRygdV+a1+5g54Ty/WFBwi+QUdjw5bvOKetTw97ieQ7OTz4stKAeVpJOM9fyS9fPA lWQWzeTtdjv+EEbyicDIy7na28RzVajgc5mqqxWWQSLuFfBESdEJG3fPjC0x3UvslJoM OOXBuQzt7rlgxrX2Fc+nkJFpoSfMwgPZdzsNJfE8eoL9jW5JFdbYHBD2JZXlfbymR9KY RdGN4nkt/sIttU7SRgsYjN6ZY9JFzRxQ1x+AmKc9DJvOyLwstouDSDkLirGNEwOflhSd Zrsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=zirBQvpMX9FN+xMGuy+YB2uuBWDRMNHlzh9gJjRPgVE=; b=htmOMMwpaXllld2aSEYOn0FB95CpmwkwTwDVKEDHb/1dLERdaAo+oupjBAVu0Z2O8W GDJjq+gV7nk90pc/pt4mFX932TObFxq42Xv+4nO+1c3oEtl2evFHtvRwxf1gxehFlnK8 4jTU0PdKpai3WU62JMUjzw5i1DG7BwjxBbZ34lngRMknGNEcPj8YS3YynRMudB+GQTnh iLKfav+uTjUdF6nxdRoeh7qb0lQ/qi8Xs/xVkiIyaLoaUWcelLfD/huhv/qTgmhb43oF BGEXT3Wgr1CPljE2UDKckTO3e16zBb1vhOrrzYTDmUlTLNRkzxPQLog+02Dg9hVioSUn IR2w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linux-foundation.org header.s=google header.b=hs+MMq9i; 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 i4si5718864pfc.26.2019.04.30.09.33.22; Tue, 30 Apr 2019 09:33: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; dkim=pass header.i=@linux-foundation.org header.s=google header.b=hs+MMq9i; 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 S1726839AbfD3Qay (ORCPT + 99 others); Tue, 30 Apr 2019 12:30:54 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:41790 "EHLO mail-lf1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726073AbfD3Qax (ORCPT ); Tue, 30 Apr 2019 12:30:53 -0400 Received: by mail-lf1-f65.google.com with SMTP id t30so11232648lfd.8 for ; Tue, 30 Apr 2019 09:30:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux-foundation.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zirBQvpMX9FN+xMGuy+YB2uuBWDRMNHlzh9gJjRPgVE=; b=hs+MMq9iB+eslb+cGLIpGLGbIv6EJP2l9mo6ehrV020sNd1PwGxPBGOEt2lJlTs3aX j5lQOg6lmmOjeQDX5ZISw6NeAcc9gXvyDHGfdKNNARf9UJs1P4nx3ChCR2owg+Zh2w30 nFun/lkPvWMpDLpdDrhOj9zXwOjyW/YZ8hGXM= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zirBQvpMX9FN+xMGuy+YB2uuBWDRMNHlzh9gJjRPgVE=; b=mtii655ngJhI1Gu0vQ34oSBubOWV9aY/za2LlhaQ5F67F0WTUIF8S5c0W+P8/qHEFS lwMhpUNgSWoXrwksOV4zTLZfnAZolrXa4q1f+yD3v0ashUJ5jEqNkPfuya/Nf/foVhQL jv74n6so2KlRds6D77BrDGCleZOpxgz6BoDDz1XfQm1HCALE2mDAGKaIlSOAGjB3ViS7 CEVEGcYgWp+tM8Ewa1EXHp3C0YvNXHSRQfedGkS5ldspbM9CXHK7DqGxq+3LlHnmTQjq RoeY5wNUm/NSIWRD//EKqu0aG2/V1v1v3EddTC6GN0nFRgkf+DnGjTy6eO/QvMP7e2NS vy0g== X-Gm-Message-State: APjAAAWRCPqWCNooXwuAvviFOvwvajQlzSTbNp2dHSmgslpd9NE0zezH O7/DpTFd47KEGP6pZwX13qixzGoeCt4= X-Received: by 2002:a19:384d:: with SMTP id d13mr16591722lfj.38.1556641851534; Tue, 30 Apr 2019 09:30:51 -0700 (PDT) Received: from mail-lf1-f46.google.com (mail-lf1-f46.google.com. [209.85.167.46]) by smtp.gmail.com with ESMTPSA id b15sm4133838ljj.1.2019.04.30.09.30.51 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 30 Apr 2019 09:30:51 -0700 (PDT) Received: by mail-lf1-f46.google.com with SMTP id t11so11222835lfl.12 for ; Tue, 30 Apr 2019 09:30:51 -0700 (PDT) X-Received: by 2002:ac2:4567:: with SMTP id k7mr36971631lfm.166.1556641462358; Tue, 30 Apr 2019 09:24:22 -0700 (PDT) MIME-Version: 1.0 References: <20190414201436.19502-1-christian@brauner.io> <20190415195911.z7b7miwsj67ha54y@yavin> <20190420071406.GA22257@ip-172-31-15-78> <20190430123901.GD23020@redhat.com> In-Reply-To: <20190430123901.GD23020@redhat.com> From: Linus Torvalds Date: Tue, 30 Apr 2019 09:24:06 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: RFC: on adding new CLONE_* flags [WAS Re: [PATCH 0/4] clone: add CLONE_PIDFD] To: Oleg Nesterov Cc: Jann Horn , Kevin Easton , Andy Lutomirski , Christian Brauner , Aleksa Sarai , "Enrico Weigelt, metux IT consult" , Al Viro , David Howells , Linux API , LKML , "Serge E. Hallyn" , Arnd Bergmann , "Eric W. Biederman" , Kees Cook , Thomas Gleixner , Michael Kerrisk , Andrew Morton , Joel Fernandes , Daniel Colascione Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Apr 30, 2019 at 5:39 AM Oleg Nesterov wrote: > > Yes, but I am wondering if man vfork should clarify what "child terminates" > actually means. I mean, the child can do clone(CLONE_THREAD) + sys_exit(), > this will wake the parent thread up before the child process exits or execs. That falls solidly into the "give people rope" category. If the vfork() child wants to mess with the parent, it has many easier ways to do it than create more threads. As mentioned, the real problem with vfork() tends to be that the child unintentionally messes with the parent because it just gets the stack sharing wrong. No need to add intention there. > I see nothing wrong, but I was always curious whether it was designed this > way on purpose or not. Oh, it's definitely on purpose. Trying to do some nested usage count would be horrendously complex, and even a trivial "don't allow any other clone() calls if we already have a vfork completion pending" is just unnecessary logic. Because at least in *theory*, there's actually nothing horribly wrong with allowing a thread to be created during the vfork(). I don't see the _point_, but it's not conceptually something that couldn't work (you'd need a separate thread stack etc, but that's normal clone()). So no, there's no safety or bogus "you can't do that". If you want to play games after vfork(), go wild. Linus