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=-2.1 required=3.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS, USER_AGENT_SANE_2 autolearn=no 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 B09E9C433DF for ; Fri, 15 May 2020 16:25:57 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 902BF20787 for ; Fri, 15 May 2020 16:25:57 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=fail reason="signature verification failed" (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b="Czl8nSVK"; dkim=fail reason="signature verification failed" (1024-bit key) header.d=hansenpartnership.com header.i=@hansenpartnership.com header.b="tEY8nMzR" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726615AbgEOQZ4 (ORCPT ); Fri, 15 May 2020 12:25:56 -0400 Received: from bedivere.hansenpartnership.com ([66.63.167.143]:50480 "EHLO bedivere.hansenpartnership.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726023AbgEOQZy (ORCPT ); Fri, 15 May 2020 12:25:54 -0400 Received: from localhost (localhost [127.0.0.1]) by bedivere.hansenpartnership.com (Postfix) with ESMTP id 350E78EE2CA; Fri, 15 May 2020 09:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1589559953; bh=oe8glbLAsYuPDWO/9J63l1A3/JX/rXGWHMdk2ewNMOA=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=Czl8nSVKq6x+5ktnGMuDJVoRjCd8L3FTEERzkB0JPBwHBwxznk411UGYdCzb5lZu1 guXqDfI5hhx4GtqifLJzgz2O7o+zakP9bsnBOCG71vbinXNa+oln+R6g4WgfNyfjcx Dabx0g7ig9tCia5NBUFs1/E7rJ8h9iOaFC99r79c= Received: from bedivere.hansenpartnership.com ([127.0.0.1]) by localhost (bedivere.hansenpartnership.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 97RosFnuv28I; Fri, 15 May 2020 09:25:53 -0700 (PDT) Received: from [153.66.254.194] (unknown [50.35.76.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by bedivere.hansenpartnership.com (Postfix) with ESMTPSA id 0DABA8EE25D; Fri, 15 May 2020 09:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=hansenpartnership.com; s=20151216; t=1589559952; bh=oe8glbLAsYuPDWO/9J63l1A3/JX/rXGWHMdk2ewNMOA=; h=Subject:From:To:Cc:Date:In-Reply-To:References:From; b=tEY8nMzR1YlR1vbSBOyT5z55J1VGQgL9BDudw6VE1ewecDFlqb3xXMh32AnzbC6a0 GT1kzr/7c46ULfMWi/Nj6X758girml/uRbappkQnXN1skHpVjas/3GLPJiLL2lQrCw JH6+lou1vP4NouYYQFthT7Aiqk1UItTX2BoqHrRA= Message-ID: <1589559950.3653.11.camel@HansenPartnership.com> Subject: Re: [PATCH v2] Implement close-on-fork From: James Bottomley To: "Karstens, Nate" , Matthew Wilcox Cc: Alexander Viro , Jeff Layton , "J. Bruce Fields" , Arnd Bergmann , Richard Henderson , Ivan Kokshaysky , Matt Turner , 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 , "a.josey@opengroup.org" Date: Fri, 15 May 2020 09:25:50 -0700 In-Reply-To: <5b1929aa9f424e689c7f430663891827@garmin.com> References: <20200515152321.9280-1-nate.karstens@garmin.com> <20200515155730.GF16070@bombadil.infradead.org> <5b1929aa9f424e689c7f430663891827@garmin.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 2020-05-15 at 16:07 +0000, Karstens, Nate wrote: > Matthew, > > What alternative would you suggest? > > From an earlier email: > > > ...nothing else addresses the underlying issue: there is no way to > > prevent a fork() from duplicating the resource. The close-on-exec > > flag partially-addresses this by allowing the parent process to > > mark a file descriptor as exclusive to itself, but there is still > > a period of time the failure can occur because the auto-close only > > occurs during the exec(). Perhaps this would not be an issue with > > a different process/threading model, but that is another discussion > > entirely. > > Do you disagree there is an issue? Oh good grief that's a leading question: When I write bad code and it crashes, most people would agree there is an issue; very few would agree the kernel should be changed to fix it. Several of us have already said the problem seems to be with the way your application is written. You didn't even answer emails like this speculating about the cause being the way your application counts resources: https://lore.kernel.org/linux-fsdevel/1587569663.3485.18.camel@HansenPartnership.com/ The bottom line is that we think you could rewrite this one application not to have the problem you're complaining about rather than introduce a new kernel API to "fix" it. James