[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Howard Chu
Subject: Re: [bug #18396] stack size setrlimit call interacts badly with Solaris/x86 kernel bug
Date: Thu, 30 Nov 2006 16:40:13 -0800
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20061116 Netscape/7.2 (ax) Firefox/1.5 SeaMonkey/1.5a

Martin Dorey wrote:
However, your point about programs invoked by make inheriting the setrlimit() is definitely something that seems problematic. Perhaps
make could change the stack limit back to what it was after it forks
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

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/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]