From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,MENTIONS_GIT_HOSTING,SPF_HELO_NONE,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 07C96C55185 for ; Wed, 22 Apr 2020 16:01:10 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id E193520774 for ; Wed, 22 Apr 2020 16:01:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726475AbgDVQBJ (ORCPT ); Wed, 22 Apr 2020 12:01:09 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:59972 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726006AbgDVQBH (ORCPT ); Wed, 22 Apr 2020 12:01:07 -0400 X-Greylist: delayed 3563 seconds by postgrey-1.37 at lindbergh.monkeyblade.net; Wed, 22 Apr 2020 09:01:07 PDT Received: from ZenIV.linux.org.uk (zeniv.linux.org.uk [IPv6:2002:c35c:fd02::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5B466C03C1A9; Wed, 22 Apr 2020 09:01:07 -0700 (PDT) Received: from viro by ZenIV.linux.org.uk with local (Exim 4.92.3 #3 (Red Hat Linux)) id 1jRHnc-008Yo8-Vd; Wed, 22 Apr 2020 16:00:33 +0000 Date: Wed, 22 Apr 2020 17:00:32 +0100 From: Al Viro To: Matthew Wilcox Cc: Nate Karstens , 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: <20200422160032.GL23230@ZenIV.linux.org.uk> References: <20200420071548.62112-1-nate.karstens@garmin.com> <20200422150107.GK23230@ZenIV.linux.org.uk> <20200422151815.GT5820@bombadil.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200422151815.GT5820@bombadil.infradead.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Apr 22, 2020 at 08:18:15AM -0700, Matthew Wilcox wrote: > On Wed, Apr 22, 2020 at 04:01:07PM +0100, Al Viro wrote: > > 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. > > https://www.mail-archive.com/austin-group-l@opengroup.org/msg05324.html > might be useful *snort* Alan Coopersmith in that thread: || https://lwn.net/Articles/785430/ suggests AIX, BSD, & MacOS have also defined || it, and though it's been proposed multiple times for Linux, never adopted there. Now, look at the article in question. You'll see that it should've been "someone's posting in the end of comments thread under LWN article says that apparently it exists on AIX, BSD, ..." The strength of evidence aside, that got me curious; I have checked the source of FreeBSD, NetBSD and OpenBSD. No such thing exists in either of their kernels, so at least that part can be considered an urban legend. As for the original problem... what kind of exclusion is used between the reaction to netlink notifications (including closing every socket, etc.) and actual IO done on those sockets?