Received: by 2002:a25:868d:0:0:0:0:0 with SMTP id z13csp614467ybk; Fri, 15 May 2020 09:06:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwwM05PFjrP56j19uVbAgfseZGEJHh8s52pD04vZjQoMxeMerBIf+BvKazTE6/SLkRz/dLz X-Received: by 2002:a17:907:447f:: with SMTP id oo23mr3358742ejb.274.1589558781506; Fri, 15 May 2020 09:06:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1589558781; cv=none; d=google.com; s=arc-20160816; b=UPstzR2FbgIVSY9X1B/r+P/mWPFAjux0ZrdVpdkpvL5y91sWc0vdeRvPWoVQp05W3A lI2hsoYzQS2uUx3t3Zj7+o2wSeYe0JKJzMHK5na9FR5QBP74dCCtyKtr4ORbaV378qz7 HH6Z1kt5ceBloIVpnhLCQYLidrfi1nBU57H3+7qLiRl9w5+Ru6VAX+S/x+BnQhb/lQrR OoJE74yFMV3m+g+Ji73e+4DiNw0wiiQ2YtnEaCJKjyDPnPy8Y32NHvehmS3Zl74Nj+qc BKcwMRY0ZgLiB/vUDdaYmVgwKWFZFqYxovKR5fPnlhD7fD5gDNbqEkdcfZlN/IVfVe6B WnIw== 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=y+KA8lBgPzad1o/ErPC+B106c9QFRlSoys6CQK+/ruw=; b=xlkU3j+JceB9UqiSpiFyZoZZJfJBP6TLVrcTJGlpr7oiNEEariDKZBEfQFCpwwufzG r42elfBU61rNnTLeejQas9xlRrGnd6SwwdJwsTZbGVS1pBeuPWq8U9PNCkmjpIOieKwI yP+eIjOMjxGQnAxFCPfSwQnTSz6Wb8DHmn4+4hjYzdjGsc+h60nH7UOLcU7dMee2rnfy sarHeaO4pgR8TvqlXyrwDf0Y+IbwQfqfKSx2YPMogNi0YhvUfDr0CA7XPZVdH5+Mvre6 b+jmryZgCaTUhnCsV3pDYL1kKoKsK0gBWZB6oCvjT9GAm4SrQdZ1EmfIBZvzPKwBfx21 l33Q== 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 j13si1548365edt.371.2020.05.15.09.05.58; Fri, 15 May 2020 09:06:21 -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 S1726945AbgEOQEf (ORCPT + 99 others); Fri, 15 May 2020 12:04:35 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49414 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-FAIL-OK-FAIL) by vger.kernel.org with ESMTP id S1726239AbgEOQEf (ORCPT ); Fri, 15 May 2020 12:04:35 -0400 Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D4127C061A0C; Fri, 15 May 2020 09:04:34 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jZcoI-009AnZ-2z; Fri, 15 May 2020 16:03:42 +0000 Date: Fri, 15 May 2020 17:03:42 +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 , Eric Dumazet , David Laight , 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: [PATCH v2] Implement close-on-fork Message-ID: <20200515160342.GE23230@ZenIV.linux.org.uk> References: <20200515152321.9280-1-nate.karstens@garmin.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200515152321.9280-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 Fri, May 15, 2020 at 10:23:17AM -0500, Nate Karstens wrote: > 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). It penalizes every call of fork() in the system (as well as adds an extra dirtied cacheline on each socket()/open()/etc.), adds memory footprint and complicates the API. All of that - to deal with rather uncommon problem that already has a portable solution. As for the Austin Group, the only authority it has ever had derives from consensus between existing Unices. "Solaris does it, Linux and *BSD do not" translates into "Austin Group is welcome to take a hike". BTW, contrary to the lovely bit of misrepresentation in that thread of theirs (" suggests that" != "someone's comment under LWN article says it _appears_ that"), none of *BSD do it. IMO it's a bad idea. NAKed-by: Al Viro