From: Andrea Arcangeli <andrea@novell.com>
To: Rik van Riel <riel@redhat.com>
Cc: linux-kernel@vger.kernel.org, Andrew Morton <akpm@osdl.org>
Subject: Re: heap-stack-gap for 2.6
Date: Sun, 26 Sep 2004 02:40:58 +0200 [thread overview]
Message-ID: <20040926004058.GR3309@dualathlon.random> (raw)
In-Reply-To: <Pine.LNX.4.44.0409251956070.28582-100000@chimarrao.boston.redhat.com>
On Sat, Sep 25, 2004 at 07:57:04PM -0400, Rik van Riel wrote:
> On Sat, 25 Sep 2004, Andrea Arcangeli wrote:
>
> > I didn't check the topdown model, in theory it should be extended to
> > cover that too, this is only working for the legacy model right now
> > because those apps aren't going to use topdown anyways.
>
> Looks like it should just work, topdown shouldn't affect
> expand_stack() or find_vma_prev() ...
expand_stack growsdown page faults are already covered.
but the mmap side of topdown doesn't seem covered instead. Think if an
application maps everything from TASK_UNMAPPED_BASE to the last byte of
heap allowed by topdown. Then userspace unmaps the nearest page to the
stack. Then the stack growsdown of 1 page. Then you mmap again for
a PAGE_SIZE area. You will then fill the gap, and that shouldn't happen,
mmap should fail instead to guarantee a failure notification to
userspace. This is what I meant with topdown not being fully covered.
BTW, I never tried to enforce a gap with MAP_FIXED, that's more a
feature than a bug, I expect people playing MAP_FIXED games, to know
what they're doing, and if they want they can also close the gap. But
they've to do it by hand. If they put a MAP_FIXED near the stack, the
growsdown page faults will then enforce the gap to be sure the stack
doesn't overwrite such MAP_FIXED.
So it's more a stack-growsdown only thing, but the get_unmapped_area
needs collaboration too to really enforce it, and that's the part
missing for topdown. MAP_FIXED is more than a stack-growsdown only thing
and so I still allow that.
next prev parent reply other threads:[~2004-09-26 0:41 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-09-25 16:22 heap-stack-gap for 2.6 Andrea Arcangeli
2004-09-25 23:57 ` Rik van Riel
2004-09-26 0:40 ` Andrea Arcangeli [this message]
2004-09-27 8:09 ` Arjan van de Ven
2004-09-27 13:09 ` Andrea Arcangeli
2004-09-28 19:43 ` Arjan van de Ven
2004-09-28 22:19 ` Andrea Arcangeli
2004-09-29 6:05 ` Arjan van de Ven
2004-09-29 14:11 ` Andrea Arcangeli
2004-09-29 14:24 ` Alan Cox
2004-09-29 15:44 ` Andrea Arcangeli
2004-09-29 14:25 ` Arjan van de Ven
2004-09-29 14:53 ` Andrea Arcangeli
2004-09-29 15:01 ` Arjan van de Ven
2004-09-29 15:40 ` Andrea Arcangeli
2004-09-28 6:25 ` Hui Huang
2004-09-28 14:19 ` Andrea Arcangeli
2004-09-29 8:42 ` Hui Huang
2004-09-29 14:23 ` Andrea Arcangeli
2004-09-29 22:01 ` Hui Huang
2004-10-12 0:51 ` Andrea Arcangeli
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=20040926004058.GR3309@dualathlon.random \
--to=andrea@novell.com \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=riel@redhat.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox