From: Al Viro <viro@zeniv.linux.org.uk>
To: Nate Karstens <nate.karstens@garmin.com>
Cc: Jeff Layton <jlayton@kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
Arnd Bergmann <arnd@arndb.de>,
Richard Henderson <rth@twiddle.net>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Helge Deller <deller@gmx.de>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
David Laight <David.Laight@aculab.com>,
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 <xiaosuo@gmail.com>
Subject: Re: [PATCH v2] Implement close-on-fork
Date: Fri, 15 May 2020 17:03:42 +0100 [thread overview]
Message-ID: <20200515160342.GE23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200515152321.9280-1-nate.karstens@garmin.com>
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 ("<LWN URL> 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 <viro@zeniv.linux.org.uk>
WARNING: multiple messages have this Message-ID (diff)
From: Al Viro <viro@zeniv.linux.org.uk>
To: Nate Karstens <nate.karstens@garmin.com>
Cc: Jeff Layton <jlayton@kernel.org>,
"J. Bruce Fields" <bfields@fieldses.org>,
Arnd Bergmann <arnd@arndb.de>,
Richard Henderson <rth@twiddle.net>,
Ivan Kokshaysky <ink@jurassic.park.msu.ru>,
Matt Turner <mattst88@gmail.com>,
"James E.J. Bottomley" <James.Bottomley@hansenpartnership.com>,
Helge Deller <deller@gmx.de>,
"David S. Miller" <davem@davemloft.net>,
Jakub Kicinski <kuba@kernel.org>,
Eric Dumazet <edumazet@google.com>,
David Laight <David.Laight@aculab.com>,
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 <xiaosuo@gmail.com>
Subject: Re: [PATCH v2] Implement close-on-fork
Date: Fri, 15 May 2020 16:03:42 +0000 [thread overview]
Message-ID: <20200515160342.GE23230@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20200515152321.9280-1-nate.karstens@garmin.com>
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 ("<LWN URL> 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 <viro@zeniv.linux.org.uk>
next prev parent reply other threads:[~2020-05-15 16:03 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-15 15:23 [PATCH v2] Implement close-on-fork Nate Karstens
2020-05-15 15:23 ` Nate Karstens
2020-05-15 15:23 ` Nate Karstens
2020-05-15 15:23 ` [PATCH v2 1/4] fs: " Nate Karstens
2020-05-15 15:23 ` Nate Karstens
2020-05-15 15:23 ` Nate Karstens
2020-05-15 15:23 ` [PATCH v2 2/4] fs: Add O_CLOFORK flag for open(2) and dup3(2) Nate Karstens
2020-05-15 15:23 ` Nate Karstens
2020-05-15 15:23 ` Nate Karstens
2020-05-15 15:23 ` [PATCH v2 3/4] fs: Add F_DUPFD_CLOFORK to fcntl(2) Nate Karstens
2020-05-15 15:23 ` Nate Karstens
2020-05-15 15:23 ` Nate Karstens
2020-05-15 15:23 ` [PATCH v2 4/4] net: Add SOCK_CLOFORK Nate Karstens
2020-05-15 15:23 ` Nate Karstens
2020-05-15 15:23 ` Nate Karstens
2020-05-15 15:30 ` [PATCH v2] Implement close-on-fork Eric Dumazet
2020-05-15 15:30 ` Eric Dumazet
2020-05-15 15:59 ` David Laight
2020-05-15 15:59 ` David Laight
2020-05-15 15:59 ` David Laight
2020-05-15 15:57 ` Matthew Wilcox
2020-05-15 15:57 ` Matthew Wilcox
2020-05-15 15:57 ` Matthew Wilcox
2020-05-15 16:07 ` Karstens, Nate
2020-05-15 16:07 ` Karstens, Nate
2020-05-15 16:25 ` James Bottomley
2020-05-15 16:25 ` James Bottomley
2020-05-15 16:25 ` James Bottomley
2020-05-15 18:28 ` Karstens, Nate
2020-05-15 18:28 ` Karstens, Nate
2020-05-15 18:28 ` Karstens, Nate
2020-05-15 18:43 ` Matthew Wilcox
2020-05-15 18:43 ` Matthew Wilcox
2020-05-15 18:43 ` Matthew Wilcox
2020-05-25 8:16 ` Pavel Machek
2020-05-25 8:16 ` Pavel Machek
2020-05-25 8:16 ` Pavel Machek
2020-05-15 16:26 ` Matthew Wilcox
2020-05-15 16:26 ` Matthew Wilcox
2020-05-15 16:26 ` Matthew Wilcox
2020-05-16 13:29 ` Christian Brauner
2020-05-16 13:29 ` Christian Brauner
2020-05-16 13:29 ` Christian Brauner
2020-05-15 16:03 ` Al Viro [this message]
2020-05-15 16:03 ` Al Viro
2020-05-15 16:26 ` Karstens, Nate
2020-05-15 16:26 ` Karstens, Nate
2020-05-15 16:53 ` David Howells
2020-05-15 16:53 ` David Howells
2020-05-15 16:53 ` David Howells
2022-06-18 11:41 ` Ralph Corderoy
2022-06-18 19:40 ` Matthew Wilcox
2022-06-18 19:40 ` Matthew Wilcox
2022-06-19 10:42 ` Ralph Corderoy
2022-06-19 10:42 ` Ralph Corderoy
2022-06-28 13:13 ` Christian Brauner
2022-06-28 13:13 ` Christian Brauner
2022-06-28 13:38 ` David Laight
2022-06-28 13:38 ` David Laight
2022-06-28 13:43 ` Christian Brauner
2022-06-28 13:43 ` Christian Brauner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200515160342.GE23230@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=David.Laight@aculab.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=arnd@arndb.de \
--cc=bfields@fieldses.org \
--cc=davem@davemloft.net \
--cc=deller@gmx.de \
--cc=edumazet@google.com \
--cc=ink@jurassic.park.msu.ru \
--cc=jlayton@kernel.org \
--cc=kuba@kernel.org \
--cc=linux-alpha@vger.kernel.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-parisc@vger.kernel.org \
--cc=mattst88@gmail.com \
--cc=nate.karstens@garmin.com \
--cc=netdev@vger.kernel.org \
--cc=rth@twiddle.net \
--cc=sparclinux@vger.kernel.org \
--cc=xiaosuo@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.