public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Andrew Morton <akpm@zip.com.au>
To: Bruce Blinn <blinn@MissionCriticalLinux.com>
Cc: Dave Anderson <anderson@mclinux.com>,
	linux-kernel@vger.kernel.org, blinn@mclinux.com
Subject: Re: [BUG][PATCH] 2.4.* mlockall(MCL_FUTURE) is broken -- child inherits  VM_LOCKED
Date: Tue, 08 Jan 2002 14:39:09 -0800	[thread overview]
Message-ID: <3C3B750D.610F7D48@zip.com.au> (raw)
In-Reply-To: <3C3B5D1B.45CBF593@mclinux.com> <3C3B6ADF.4AAABE58@zip.com.au> <3C3B702C.4BF3819@MissionCriticalLinux.com>

Bruce Blinn wrote:
> 
> Andrew Morton wrote:
> >
> > Dave Anderson wrote:
> > >
> > > In 2.4.*, mlockall(MCL_FUTURE) is erroneously inherited by child processes
> > > across fork() and exec():
> >
> > The Linux manpage says that it is not inherited across either.
> >
> > However SUS says that it is not inherited across exec, and
> > doesn't mention fork() at all.
> > http://www.opengroup.org/onlinepubs/007908799/xsh/mlockall.html
> >
> > So...  Shouldn't we be clearing it in the exec() path?
> >
> 
> But, the SUS documentation for fork() says that it does not inherit the
> memory locks of the parent.  It explicitly mentions mlockall().
> 
>         http://www.opengroup.org/onlinepubs/007908799/xsh/fork.html

So it does.  So clearing it on fork is correct.  And my comment
regarding def_flags was nonsense.  Probably it's best to explicitly
clear VM_LOCKED, just in case something else gets added to def_flags
in the future.

Apart from that - ship it :)

-

      reply	other threads:[~2002-01-08 22:44 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-01-08 20:56 [BUG][PATCH] 2.4.* mlockall(MCL_FUTURE) is broken -- child inherits VM_LOCKED Dave Anderson
2002-01-08 21:55 ` Andrew Morton
2002-01-08 22:18   ` Bruce Blinn
2002-01-08 22:39     ` Andrew Morton [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=3C3B750D.610F7D48@zip.com.au \
    --to=akpm@zip.com.au \
    --cc=anderson@mclinux.com \
    --cc=blinn@MissionCriticalLinux.com \
    --cc=blinn@mclinux.com \
    --cc=linux-kernel@vger.kernel.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