arch_get_unmapped_area_topdown vs stack reservations

PATCH Martin J. Bligh 2 participants 4 messages Aug 17, 2004 – Aug 18, 2004

Subsystems (2)

Memory management Memory mapping

lore

Share & tools

lore

Martin J. Bligh

author

2004-08-17 22:18 UTC #0 lore raw

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 <[email protected]>

mm/mmap.c renamed from home/linux/views/linux-2.6.8.1-mm1/mm/mmap.c +1 -1

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
@@ -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 [email protected]. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"[email protected]"> [email protected] </a>

Arjan van de Ven

2004-08-18 06:11 UTC #1 lore raw

Quoted 4 lines · 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?

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

Martin J. Bligh

author

2004-08-18 06:18 UTC #2 lore raw

--Arjan van de Ven <[email protected]> wrote (on Wednesday, August 18, 2004 08:11:21 +0200):

Quoted 7 lines · Martin J. Bligh

Quoted 4 lines
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.

Quoted 1 line

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?

Arjan van de Ven

2004-08-18 06:36 UTC #3 lore raw

Quoted 10 lines · Martin J. Bligh

--Arjan van de Ven <[email protected]> wrote (on Wednesday, August 18, 2004 08:11:21 +0200):
Quoted 7 lines · Martin J. Bligh
Quoted 4 lines
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...

Quoted 8 lines

Yeah, wasn't meant as a criticism of the new layout, just a general improvement, perhaps.
Quoted 1 line
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.