From: Linus Torvalds <torvalds@transmeta.com>
To: "Eric W. Biederman" <ebiederm+eric@ccr.net>
Cc: linux-kernel@vger.rutgers.edu, linux-mm@kvack.org
Subject: Re: vfork & co bugfix
Date: Sun, 10 Jan 1999 23:31:34 -0800 (PST) [thread overview]
Message-ID: <Pine.LNX.3.95.990110232846.1997K-100000@penguin.transmeta.com> (raw)
In-Reply-To: <m13e5i47n4.fsf@flinx.ccr.net>
On 11 Jan 1999, Eric W. Biederman wrote:
>
> >> Question. Why don't we let CLONE_VFORK be a standard clone flag?
>
> LT> Because then we're back to the old problem: before doing a vfork(),
> LT> somebody could do a "clone(CLONE_VFORK)" (which would _not_ wait on the
> LT> semaphore like a real vfork() would), and now the wrong child can wake up
> LT> the parent and mess up the real vfork().
>
> Sorry. I had the implicit assumption that if CLONE_VFORK was a
> standard clone flag, do_fork would include the five lines of semaphore
> code.
Oh, ok.
Sure, makes sense, and is probably the right thing to do - that way you
can (if you really want to) do some strange half-way vfork(), half-way
clone() thing where you share your file descriptors in a vfork().
I don't know how useful it would be, but it would be no uglier than doing
it any other way, and I see some advantages (no need for a separate
vfork() system call - clone() can do it directly).
I thus remove all my objections,
Linus
--
This is a majordomo managed list. To unsubscribe, send a message with
the body 'unsubscribe linux-mm me@address' to: majordomo@kvack.org
prev parent reply other threads:[~1999-01-11 7:31 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-10 6:48 Eric W. Biederman
1999-01-10 18:04 ` Linus Torvalds
1999-01-10 21:34 ` Eric W. Biederman
1999-01-11 4:32 ` Eric W. Biederman
1999-01-11 6:35 ` Linus Torvalds
1999-01-11 6:59 ` Eric W. Biederman
1999-01-11 7:31 ` Linus Torvalds [this message]
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=Pine.LNX.3.95.990110232846.1997K-100000@penguin.transmeta.com \
--to=torvalds@transmeta.com \
--cc=ebiederm+eric@ccr.net \
--cc=linux-kernel@vger.rutgers.edu \
--cc=linux-mm@kvack.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox