Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp794478ybz; Wed, 22 Apr 2020 08:08:09 -0700 (PDT) X-Google-Smtp-Source: APiQypJzsw/l8VQVO2WR/OnnypTdT9eXDLie+wo1l5udOfbgeVshRBkRxtHE9/pxTRouZvONr2VM X-Received: by 2002:a17:906:e90:: with SMTP id p16mr13100945ejf.14.1587568088854; Wed, 22 Apr 2020 08:08:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587568088; cv=none; d=google.com; s=arc-20160816; b=LKG7Y43tf+5XvNwIMjyW/SO5HKcKclWF6+njfWXOdqZKQmYySbsck/8QYVn/+2zMPI QVFQwZepN/U9CUXxTHEyo7BTPex2/E7b0ALEaloHHk0g4XtpCpKBnwDtwzqWfGpj9ZrC VltP7A8NMPKRS+BS4BTLA6A6W50WYWzcPLjxY4QA/JyAgAz12/UUVS4NMxdH1nF+VzuR N7BNh3QOM5WOUVx9IrB2eaXlb+Qx+Xv5q7ozCtJYfJznNyATUpPpwSHqy0yFuMu/FVh9 9sDQlPX2wz3bf2CH4K8nT4yVpmerPwuxcNd33SiBS8Jw98e6UM0gKboOhCgODStN2b1z /r/w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date; bh=la/QX1SDGe1lXG4c6rXb3Khv4HgbxZvOipwMqEzypOY=; b=mmdivRdJ7cNcahz20ImN8lceqbxz/V0UYB3nilL9Rg7vxegwGnos+GvTKlOOhw9BOz 3r1RYW4ccPWG+BGNf2L8xYhANxcBNZg76kO0l215waH4PZX66deJEediw857Sn8Cb5kd g5khtBa0GVXXcRJrPgqR6/Rfirp+EiQ6HapGG32uBNElqdg8dBBlkfHaO1aHJAITTVKa YPBtwq7pr4GZnfNWRiuK1MdyctcnJk5Hv/fzoJsDsugHT1Lej2KY+w2zsePoq2RdJObE ijXKfNgYKKYh2pTaHpiqS7KFp5eSKYgk86bgMzA27ICt90Arbh/3leUPnPzHtB9PF24n 5Msw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id q24si3630638ejz.458.2020.04.22.08.07.23; Wed, 22 Apr 2020 08:08:08 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727949AbgDVPBp (ORCPT + 99 others); Wed, 22 Apr 2020 11:01:45 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50776 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725934AbgDVPBo (ORCPT ); Wed, 22 Apr 2020 11:01:44 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 73E41C03C1A9; Wed, 22 Apr 2020 08:01:44 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jRGs7-008WRP-P8; Wed, 22 Apr 2020 15:01:07 +0000 Date: Wed, 22 Apr 2020 16:01:07 +0100 From: Al Viro To: Nate Karstens Cc: Jeff Layton , "J. Bruce Fields" , Arnd Bergmann , Richard Henderson , Ivan Kokshaysky , Matt Turner , "James E.J. Bottomley" , Helge Deller , "David S. Miller" , Jakub Kicinski , linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org, linux-alpha@vger.kernel.org, linux-parisc@vger.kernel.org, sparclinux@vger.kernel.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org, Changli Gao Subject: Re: Implement close-on-fork Message-ID: <20200422150107.GK23230@ZenIV.linux.org.uk> References: <20200420071548.62112-1-nate.karstens@garmin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200420071548.62112-1-nate.karstens@garmin.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Apr 20, 2020 at 02:15:44AM -0500, Nate Karstens wrote: > Series of 4 patches to implement close-on-fork. Tests have been > published to https://github.com/nkarstens/ltp/tree/close-on-fork. > > close-on-fork addresses race conditions in system(), which > (depending on the implementation) is non-atomic in that it > first calls a fork() and then an exec(). > > This functionality was approved by the Austin Common Standards > Revision Group for inclusion in the next revision of the POSIX > standard (see issue 1318 in the Austin Group Defect Tracker). What exactly the reasons are and why would we want to implement that? Pardon me, but going by the previous history, "The Austin Group Says It's Good" is more of a source of concern regarding the merits, general sanity and, most of all, good taste of a proposal. I'm not saying that it's automatically bad, but you'll have to go much deeper into the rationale of that change before your proposal is taken seriously.