From: Matthew Wilcox <willy@infradead.org>
To: Nate Karstens <nate.karstens@garmin.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
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>,
a.josey@opengroup.org
Subject: Re: [PATCH v2] Implement close-on-fork
Date: Fri, 15 May 2020 08:57:30 -0700 [thread overview]
Message-ID: <20200515155730.GF16070@bombadil.infradead.org> (raw)
In-Reply-To: <20200515152321.9280-1-nate.karstens@garmin.com>
On Fri, May 15, 2020 at 10:23:17AM -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
> and cover close-on-fork functionality in the following syscalls:
[...]
> 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).
NAK to this patch series, and the entire concept.
Is there a way to persuade POSIX that they made a bad decision by
standardising this mess?
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Nate Karstens <nate.karstens@garmin.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
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>,
a.josey@opengroup.
Subject: Re: [PATCH v2] Implement close-on-fork
Date: Fri, 15 May 2020 08:57:30 -0700 [thread overview]
Message-ID: <20200515155730.GF16070@bombadil.infradead.org> (raw)
In-Reply-To: <20200515152321.9280-1-nate.karstens@garmin.com>
On Fri, May 15, 2020 at 10:23:17AM -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
> and cover close-on-fork functionality in the following syscalls:
[...]
> 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).
NAK to this patch series, and the entire concept.
Is there a way to persuade POSIX that they made a bad decision by
standardising this mess?
WARNING: multiple messages have this Message-ID (diff)
From: Matthew Wilcox <willy@infradead.org>
To: Nate Karstens <nate.karstens@garmin.com>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>,
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>,
a.josey@opengroup.
Subject: Re: [PATCH v2] Implement close-on-fork
Date: Fri, 15 May 2020 15:57:30 +0000 [thread overview]
Message-ID: <20200515155730.GF16070@bombadil.infradead.org> (raw)
In-Reply-To: <20200515152321.9280-1-nate.karstens@garmin.com>
On Fri, May 15, 2020 at 10:23:17AM -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
> and cover close-on-fork functionality in the following syscalls:
[...]
> 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).
NAK to this patch series, and the entire concept.
Is there a way to persuade POSIX that they made a bad decision by
standardising this mess?
next prev parent reply other threads:[~2020-05-15 15:57 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 [this message]
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
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=20200515155730.GF16070@bombadil.infradead.org \
--to=willy@infradead.org \
--cc=David.Laight@aculab.com \
--cc=James.Bottomley@hansenpartnership.com \
--cc=a.josey@opengroup.org \
--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=viro@zeniv.linux.org.uk \
--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.