Re: Stack expansion on ia64

David Mosberger wrote:
> That's exactly the problem!  Ignoring the ia32 bits, the patch goes:
> 
> +               if (user_mode(regs)) {
> +                       stack_lim = regs->r12;
> +                       if (address < stack_lim)
> +                               goto bad_area;
> +               }
> 
> Why would it make sense to compare regs->r12 against the faulting
> address for a MAP_GROWS_DOWN vm_area which has nothing to do with the
> normal memory stack?
> 

The way I look at it is: any address outside of legally mapped VMAs is illegal and should generate a SIGSEGV. The kernel makes an exception for the stack(s). Currently, the kernel assumes that all MAP_GROWS_DOWN areas are for stacks and expands them.

My patch removes that assumption by introducing an explicit check, narrowing the circumstances under which the exception is granted. This should help programmers catch more bugs in their code, which would otherwise be masked by stack expansion. Examples include:

a) illegal accesses to any address between vma2 and vma_stack don't generate SIGSEGV.

    mm: vma1 -> vma2 -> vma_stack

b) In a multithreaded case:

    mm: vma1 -> vma2 -> vma_stack1 -> vma3 -> vma_stack2

   with two threads t1 (using vma_stack1) and t2 (using vma_stack2). Now, if t1 makes an illegal access to an address between vma3 and vma_stack2, it should generate a SIGSEGV.

>   Arun> Also, there is nothing that says that all MAP_GROWS_DOWN areas
>   Arun> are auto expanded :)
> 
> Why not?  What semantics do you suggest for MAP_GROWSDOWN?
> 

I think of MAP_GROWSDOWN as a hint to the kernel that this may be a stack segment. A necessary, but not sufficient condition to identify the stack.

> And why is this a reason to break an existing feature of the Linux
> kernel? 

This behavior is different across architectures. i386 has a different behavior.

	-Arun

-
To unsubscribe from this list: send the line "unsubscribe linux-ia64" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html