linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
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

      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