Re: [bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug

[Howard Chu]

Martin Dorey wrote:
> > However, your point about programs invoked by make inheriting the 
> > setrlimit() is definitely something that seems problematic.  Perhaps
> >     
> GNU 
>   
> > make could change the stack limit back to what it was after it forks
> >     
> but 
>   
> > before it execs its child.  I wonder what happens if you change a
> >     
> limit to 
>   
> > something too small for the current processes resources?
> >     
>
> It doesn't look specified by
> http://www.opengroup.org/onlinepubs/009695399/functions/getrlimit.html.
>
> This test suggests that it works fine on my Linux box.  I presume the
> limit check is normally done on a faulting access off the end of the
> stack, so setrlimit would need some to have some different and special
> code to check the current stack usage if it wanted to apply the check
> immediately.  It seems a bit unlikely that anyone would have gone to
> that effort, thus stopping you from doing something useful in this sort
> of situation.
>   

In Linux (and most other Unix systems) the stack is allocated in 
page-sized chunks, and an extra page with no access permissions is 
mapped at the end of it. Accessing that page is what generates the SEGV 
that occurs when you overrun the stack. The mappings are only 
established when the stack is grown, and generally the stack never 
shrinks. So if you already have X pages of stack legitimately in use, 
lowering the rlimit isn't going to have an immediate effect. I.e., the 
stack growth occurred before the limit decreased. In general, Unix 
doesn't impose restrictions retroactively. (E.g., if you open a file and 
have a valid descriptor on it, and someone else chmods the file, 
removing your access permissions, you still have your original 
privileges through the open descriptor.)

--
 -- Howard Chu
 Chief Architect, Symas Corp.  http://www.symas.com
 Director, Highland Sun        http://highlandsun.com/hyc
 OpenLDAP Core Team            http://www.openldap.org/project/