Linux-Fsdevel Archive on lore.kernel.org
 help / color / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Matthew Wilcox <willy@infradead.org>, Al Viro <viro@zeniv.linux.org.uk>
Cc: Nate Karstens <nate.karstens@garmin.com>,
	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>, Helge Deller <deller@gmx.de>,
	"David S. Miller" <davem@davemloft.net>,
	Jakub Kicinski <kuba@kernel.org>,
	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: Implement close-on-fork
Date: Wed, 22 Apr 2020 08:34:23 -0700
Message-ID: <1587569663.3485.18.camel@HansenPartnership.com> (raw)
In-Reply-To: <20200422151815.GT5820@bombadil.infradead.org>

On Wed, 2020-04-22 at 08:18 -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.ht
> ml
> might be useful

So the problem is an application is written in such a way that the time
window after it forks and before it execs can cause a file descriptor
based resource to be held when the application state thinks it should
have been released because of a mismatch in the expected use count?

Might it not be easier to rewrite the application for this problem
rather than the kernel?  Especially as the best justification in the
entire thread seems to be "because solaris had it".

James


  reply index

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-20  7:15 Nate Karstens
2020-04-20  7:15 ` [PATCH 1/4] fs: " Nate Karstens
2020-04-20 10:25   ` Eric Dumazet
2020-04-22  3:38     ` Changli Gao
2020-04-22  3:41       ` Changli Gao
2020-04-22  8:35     ` David Laight
2020-05-01 14:45     ` Karstens, Nate
2020-05-01 15:23       ` Matthew Wilcox
2020-05-03 13:52       ` David Laight
2020-04-22 15:36   ` Karstens, Nate
2020-04-22 15:43     ` Matthew Wilcox
2020-04-22 16:02       ` Karstens, Nate
2020-04-22 16:31         ` Bernd Petrovitsch
2020-04-22 16:55           ` David Laight
2020-04-23 12:34             ` Bernd Petrovitsch
2020-04-20  7:15 ` [PATCH 2/4] fs: Add O_CLOFORK flag for open(2) and dup3(2) Nate Karstens
2020-04-20  7:15 ` [PATCH 3/4] fs: Add F_DUPFD_CLOFORK to fcntl(2) Nate Karstens
2020-04-20  7:15 ` [PATCH 4/4] net: Add SOCK_CLOFORK Nate Karstens
2020-04-22 14:32 ` Implement close-on-fork James Bottomley
2020-04-22 15:01 ` Al Viro
2020-04-22 15:18   ` Matthew Wilcox
2020-04-22 15:34     ` James Bottomley [this message]
2020-04-22 16:00     ` Al Viro
2020-04-22 16:13       ` Al Viro
2020-05-04 13:46       ` Karstens, Nate

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=1587569663.3485.18.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=arnd@arndb.de \
    --cc=bfields@fieldses.org \
    --cc=davem@davemloft.net \
    --cc=deller@gmx.de \
    --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=willy@infradead.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

Linux-Fsdevel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-fsdevel/0 linux-fsdevel/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-fsdevel linux-fsdevel/ https://lore.kernel.org/linux-fsdevel \
		linux-fsdevel@vger.kernel.org
	public-inbox-index linux-fsdevel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.linux-fsdevel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git