arch_get_unmapped_area_topdown vs stack reservations

arch_get_unmapped_area_topdown vs stack reservations

[Martin J. Bligh]

I worry that the current code will allow us to intrude into the 
reserved stack space with a vma allocation if it's requested at
an address too high up. One could argue that they got what they
asked for ... but not sure we should be letting them do that?

Is the following change acceptable? Not tested yet, but will do
if you're happy with it.

Signed-off-by: Martin J. Bligh <mbligh@aracnet.com>

diff -purN -X /home/mbligh/.diff.exclude /home/linux/views/linux-2.6.8.1-mm1/mm/mmap.c 2.6.8.1-mm1-topdown_fix/mm/mmap.c
--- /home/linux/views/linux-2.6.8.1-mm1/mm/mmap.c	2004-08-17 14:43:07.000000000 -0700
+++ 2.6.8.1-mm1-topdown_fix/mm/mmap.c	2004-08-17 14:52:55.000000000 -0700
@@ -1101,7 +1101,7 @@ arch_get_unmapped_area_topdown(struct fi
 	if (addr) {
 		addr = PAGE_ALIGN(addr);
 		vma = find_vma(mm, addr);
-		if (TASK_SIZE - len >= addr &&
+		if (base - len >= addr &&
 				(!vma || addr + len <= vma->vm_start))
 			return addr;
 	}

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: arch_get_unmapped_area_topdown vs stack reservations

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 400 bytes --]

On Tue, Aug 17, 2004 at 03:18:34PM -0700, Martin J. Bligh wrote:
> I worry that the current code will allow us to intrude into the 
> reserved stack space with a vma allocation if it's requested at
> an address too high up. One could argue that they got what they
> asked for ... but not sure we should be letting them do that?

well even the non-flexmmap code allows this.... what is the problem ?


[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: arch_get_unmapped_area_topdown vs stack reservations

[Martin J. Bligh]

--Arjan van de Ven <arjanv@redhat.com> wrote (on Wednesday, August 18, 2004 08:11:21 +0200):

> On Tue, Aug 17, 2004 at 03:18:34PM -0700, Martin J. Bligh wrote:
>> I worry that the current code will allow us to intrude into the 
>> reserved stack space with a vma allocation if it's requested at
>> an address too high up. One could argue that they got what they
>> asked for ... but not sure we should be letting them do that?
> 
> well even the non-flexmmap code allows this...

Yeah, wasn't meant as a criticism of the new layout, just a general
improvement, perhaps.

> what is the problem ?

Just that if they allocate right up to the stack, we'll go boom shortly
afterwards. I guess the question is ... what exactly are the rules
for stack space reservations?

M.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

Re: arch_get_unmapped_area_topdown vs stack reservations

[Arjan van de Ven]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

On Tue, Aug 17, 2004 at 11:18:30PM -0700, Martin J. Bligh wrote:
> --Arjan van de Ven <arjanv@redhat.com> wrote (on Wednesday, August 18, 2004 08:11:21 +0200):
> 
> > On Tue, Aug 17, 2004 at 03:18:34PM -0700, Martin J. Bligh wrote:
> >> I worry that the current code will allow us to intrude into the 
> >> reserved stack space with a vma allocation if it's requested at
> >> an address too high up. One could argue that they got what they
> >> asked for ... but not sure we should be letting them do that?
> > 
> > well even the non-flexmmap code allows this...
> 
> Yeah, wasn't meant as a criticism of the new layout, just a general
> improvement, perhaps.
> 
> > what is the problem ?
> 
> Just that if they allocate right up to the stack, we'll go boom shortly
> afterwards. I guess the question is ... what exactly are the rules
> for stack space reservations?

well... unless you have a VERY good reason I would see it as rude to prevent
this, I mean, the user *asks* for this address. Posix and co I'm sure don't
allow you to deny it unless it's really busy. 
Or say the user unmaps the stack (after allocating a new one and changing
esp).... the kernel then would not allow a new area to be mapped there
either.... smells like something the kernel should not enforce to me.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]